Kobi,Thanks for your quick reply. Unfortunately the last ACK to the provider doesn't have a contact header in it, so I don't think this will do anything..
Here's the last invite that goes to the provider: INVITE sip:[email protected]<sip%[email protected]>SIP/2.0. Record-Route: <sip:70.99.100.101;lr=on>. Via: SIP/2.0/UDP 70.99.100.101;branch=z9hG4bKa252.d9e0fc8.0. Via: SIP/2.0/UDP 208.124.125.126:5060 ;received=208.124.125.126;rport=5060;branch=z9hG4bKc0a80c0c0000003049adcae6226108aa00000032. Content-Length: 370. Contact: <sip:[email protected]:5060>. Call-ID: [email protected]. Content-Type: application/sdp. CSeq: 1 INVITE. From: "unknown"<sip:[email protected] <sip%[email protected]> >;tag=34708247451729444157. Max-Forwards: 69. To: <sip:[email protected] <sip%[email protected]>>. User-Agent: SJphone/1.60.299a/L (SJ Labs). And here's the last ACK.. which is subsequently the last packet on the call, ever (unless the originator, customer, hangs up) ACK sip:[email protected]<sip%[email protected]>SIP/2.0. Record-Route: <sip:70.99.100.101;lr=on>. Via: SIP/2.0/UDP 70.99.100.101;branch=z9hG4bKa252.d9e0fc8.2. Via: SIP/2.0/UDP 208.124.125.126:5060 ;received=208.124.125.126;rport=5060;branch=z9hG4bKc0a80c0c0000003049adcb09107fe28800000037. Content-Length: 0. Call-ID: [email protected]. CSeq: 1 ACK. From: "unknown"<sip:[email protected] <sip%[email protected]> >;tag=34708247451729444157. Max-Forwards: 69. Route: <sip:204.13.14.15;lr=on;ftag=34708247451729444157>. To: <sip:[email protected] <sip%[email protected]> >;tag=as59051861. User-Agent: SJphone/1.60.299a/L (SJ Labs). On Tue, Mar 3, 2009 at 7:00 PM, Kobi Eshun <[email protected]> wrote: > Don't know if this will help you, but we ran into a similar problem with > one of our PSTN providers. In essence, their GW (incorrectly) updated the > contact info of an established dialog when it got an ACK. In our case, the > ACK sometimes contained a contact with an RFC 1918 IP address, and > subsequent in-dialog requests from the remote GW would be lost. This code > snippet addressed the issue: > if (loose_route()) { > xlog ("L_DBG", "loose_route;$rm\n"); > if(is_method("ACK")) { > if(is_present_hf("Contact")) remove_hf("Contact"); > }; > }; > > > Be interested to hear how you resolve this. Cheers, > -- > kobi > > > - Show quoted text - > On Mar 3, 2009, at 4:41 PM, Brett Nemeroff wrote: > > - Show quoted text - > Question... > In general the receipient of an INVITE should respond to that invite to the > address in the contact header, right? > > What if there is a record-route header? That should prevail, right? > > I'm having a problem that with a single provider, some (not all) calls they > don't send the BYE from the FAR side of the call back via me, instead it > goes direct to the originator. > > Example: > > My customer places a call to me. I send to my provider. Provider sends it > to destination. > > Destination hangs up, BYE goes to my customer instead of me.. My INVITE to > my provider DOES have a record-route header init. > > Originally, this problem began because my customer would reinvite the call > right after the call was established and the re-invite, because it was > in-dialog wouldn't get record routed. > > So I moved my record-route block to before my loose route block. Now, > sometimes I get byes.. I'm not sure what I'm doing wrong.. any ideas? > -Brett > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
