[OpenSIPS-Users] Slight problem routing 100s and 183s

[Nick Khamis]

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.