[OpenSER-Users] recover from previous strict routing triggered incorrectly in ALG scenario

Andrew Pogrebennyk andrew.pogrebennyk at portaone.com
Wed May 7 22:36:32 CEST 2008


Hi Bogdan,
I'm a bit surprised by your question. OpenSER works in ALG mode - 
connects two disconnected networks. So it inserts 2 Record-Routes 
(enable_double_rr parameter of rr module is enabled by default). On the 
public side OpenSER talks to b2bua. b2bua memorizes Record-Routes and 
when it receives BYE that it must send further to OpenSER, it inserts 
Route headers with both IPs of OpenSER - those it originally got in 
Record-Routes.

To explain it further, end device 10.0.1.2 is connected to OpenSER ALG 
via VPN. OpenSER listens on the private IP 10.0.0.100 that is directly 
reachable for the client, and public IP a.b.c.d. Device is configured 
with IP address of proxy/b2bua as "domain" (let's call it w.x.y.z) and 
private IP address of OpenSER ALG 10.0.0.100 - as an outgoing proxy.

So when it calls it sends for example such INVITE to OpenSER 10.0.0.100:

INVITE sip:cld at w.x.y.z SIP/2.0
Via: SIP/2.0/UDP 
10.0.1.2:8304;branch=z9hG4bK-d87543-e31904647634642f-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:user at 10.0.1.2:8304>
To: <sip:cld at w.x.y.z>
From: <sip:user at w.x.y.z>;tag=a1255825
...

OpenSER proxies this INVITE from private to public interface and then to 
proxy/b2bua that it talks to. The latter receives it with such headers 
(I believe vias, from and to can be omitted):

INVITE sip:cld at w.x.y.z SIP/2.0
Record-Route: 
<sip:a.b.c.d;r2=on;lr;ftag=6751d9e2-80fb-1810-8010-0015c5bf2da5>
Record-Route: 
<sip:10.0.0.100;r2=on;lr;ftag=6751d9e2-80fb-1810-8010-0015c5bf2da5>
Contact: sip:user at a.b.c.d

The call eventually gets connected. Some time later the callee gets 
bored and sends BYE. Its contents are not relevant here - remember that 
it talks to b2bua. b2bua puts Route headers and finally sends the 
following request to OpenSER:

BYE sip:user at a.b.c.d SIP/2.0
Via: SIP/2.0/UDP 
w.x.y.z;branch=z9hG4bK4f44.b91363e99e6c107e32eda5c5526933be.0
Via: SIP/2.0/UDP 
w.x.y.z:5061;branch=z9hG4bK5bcae8426bb383dcf815d7db04dbaacf;rport=5061
Route: <sip:a.b.c.d;r2=on;lr;ftag=6751d9e2-80fb-1810-8010-0015c5bf2da5>
Route: <sip:10.0.0.100;r2=on;lr;ftag=6751d9e2-80fb-1810-8010-0015c5bf2da5>

And this particular BYE confuses OpenSER. Hope I've been clear enough. 
Now who's at fault?
I can send OpenSER config and detailed log files to your private email 
if you deem it necessary.

Thanks,

Bogdan-Andrei Iancu wrote:
> Hi Andrew,
> 
> Just a short question - how comes that your BYE has proxy ips in RURI 
> and Route ? where the end-device IP ??
> 
> Regards,
> Bogdan
> 
> Andrew Pogrebennyk wrote:
>> Hi,
>> Im'm cross-posting this from OpenSER-Devel because I am not 100% sure 
>> this is a bug.
>>
>> I am trying to create openser configuration for proxy that connects 
>> private (VPN) network with public network. I started with a config 
>> similar to http://voipembedded.com/resources/openser_cr.cfg, added a 
>> call to force_send_socket() to send from public IP and 
>> rtpproxy/nathelper in bridge mode. As per config loose_route() is 
>> called from openser.cfg to route a sequential request within a dialog 
>> through record-routing.
>> Now when a BYE from callee comes in, it contains two Route headers: 
>> Route: <a.b.c.d;r2=on;lr;ftag=...> where a.b.c.d is server's public 
>> IP, Route: <10.0.0.100;r2=on;lr;ftag=...> where 10.0.0.100 is a 
>> private IP and username at a.b.c.d in Request-URI.

-- 
Sincerely,
Andrew Pogrebennyk




More information about the sr-users mailing list