Hello Nick, Last time I check Canada was still in the North Hemisphere, so summer should come :)....We are just ending the spring here in Europe.
So, the new box is the OUT one ? I'm asking as your trace shows the .5 IP which belong to the IN server >From your description I do not really understand what is the actual 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:15148392...@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@192.168.2.11. vs > Call-ID: 1f5b92da3d973b2b7a6fb2752e8df585@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@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users