No subject

problem - maybe you can off list send me a pcap of the call with some
more details.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/16/2013 09:02 PM, Nick Khamis wrote:
> Hello Everyone,
>
> Hope all is well. Here in Canada our 2 weeks of summer is almost over
> and now it's almost autumn ;). Those of you who are in Montreal know
> what I am talking about....
>
> Long story short, we love OpenSIPS so much that we decided to add
> another box between our media servers and our service provider,
> yielding a:
>
> NAT Box   <----> OpenSIPSIn   <------> Asterisk1...N <-------->OpenSIPSOut
>
> OpenSIPSIn: 192.168.2.5
> Asterisk: 192.168.2.10
> OpenSIPSOut: 192.168.2.20
>
> Everything was working fine in our natted environment until we added
> OpenSIPSOut.
> Looking at the trace, I see a problem with via and rr. The trace from
> OpenSIPSIn:
>
> U 2013/05/16 13:12:53.978573 192.168.2.5:5060 -> 192.168.2.10:5060
> INVITE sip:15148392007 at server.example.com:5060;user=phone SIP/2.0.
> Record-Route: <sip:192.168.2.5;lr;did=66a.32d38963>.
> Via: SIP/2.0/UDP 192.168.2.5:5060;branch=z9hG4bKd9a4.dfbf0a33.0.
> Via: SIP/2.0/UDP
> 192.168.2.11:5060;rport=5060;received=192.168.2.11;branch=z9hG4bKc3495b99FCBA96F0.
>
>
> Then the "Giving a Try" coming in from our services provider to OpenSIPSIn
> do not get responded to:
>
>
> U 2013/05/16 13:12:54.177744 10.5.2.13:5060 -> 192.168.2.5:5060
> SIP/2.0 100 Giving a try.
> Via: SIP/2.0/UDP
> 192.168.2.20:5060;received=79.12.11.7;branch=z9hG4bK5b6b.146a4f8.0.
> Via: SIP/2.0/UDP
> 192.168.2.10:5060;received=192.168.2.10;branch=z9hG4bK1225fb65;rport=5060.
>
> Givng a try
>
> Givng a try
>
> Givng a try
>
> .....
>
> And so is the case for "Session Progress" coming in from our service provider:
>
> U 2013/05/16 13:13:07.655052 10.5.2.13:5060 -> 192.168.2.5:5060
> SIP/2.0 183 Session Progress.
> Via: SIP/2.0/UDP 192.168.2.20:5060;branch=z9hG4bK5b6b.146a4f8.0.
> Via: SIP/2.0/UDP
> 192.168.2.10:5060;received=192.168.2.10;branch=z9hG4bK1225fb65;rport=5060.
> Record-Route: <sip:192.168.2.20;lr;did=4e7.35cb3c86>.
>
> Session Progress
>
> Session Progress
>
> Session Progress
>
> .....
>
> To make things more interesting, asterisk creates a new callid when
> receiving the initial request from OpenSIPSIn:
>
> Call-ID: 16a8997f-217a7945-ca8ec106 at 192.168.2.11. vs
> Call-ID: 1f5b92da3d973b2b7a6fb2752e8df585 at 192.168.2.10:5060.
>
> In the past, we handled BYEs getting 404'ed by opensips because of the change in
> callid by explicitly forcing the dialog matching using match/validate/
> and fix_route_dialog() (Thanks Vlad! ;)
>
> Would we force dialog matching for the 100 and 180's the same way we
> did for BYEs?
> If so where would be the safest place to do this.
>
> Thanks in Advance,
>
> Nick.
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>