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

[Bogdan-Andrei Iancu]

Hi Andrew,

My question was about the BYE request - all the routing information 
(Route+RURI) are pointing to your server - I find this a bit strange as 
there is no information about the end device (where openser should send 
further the request).

If I understand correctly your scenario, it seams you change the contact 
IP from INVITE into the openser IP - this is not good as it will make 
impossible to make difference between loose route and strict route.

So your problem is that you put in INVITE's contact the server IP.

Regards,
Bogdan

Andrew Pogrebennyk wrote:
> 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.
>