[OpenSIPS-Users] loose routing question

Brett Nemeroff brett at nemeroff.com
Wed Mar 4 02:25:50 CET 2009


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:0123455219848071234 at 204.13.14.15<sip%3A0123455219848071234 at 204.13.14.15>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:anonymous at 208.124.125.126:5060>.

Call-ID: 3843BD36-1DD2-11B2-8F19-FE592D5F1AFE at 192.168.12.12.

Content-Type: application/sdp.

CSeq: 1 INVITE.

From: "unknown"<sip:anonymous at 70.99.100.101 <sip%3Aanonymous at 70.99.100.101>
>;tag=34708247451729444157.

Max-Forwards: 69.

To: <sip:5219848071234 at 70.99.100.101 <sip%3A5219848071234 at 70.99.100.101>>.

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:0123455219848071234 at 204.13.233.223<sip%3A0123455219848071234 at 204.13.233.223>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: 3843BD36-1DD2-11B2-8F19-FE592D5F1AFE at 192.168.12.12.

CSeq: 1 ACK.

From: "unknown"<sip:anonymous at 70.99.100.101 <sip%3Aanonymous at 70.99.100.101>
>;tag=34708247451729444157.

Max-Forwards: 69.

Route: <sip:204.13.14.15;lr=on;ftag=34708247451729444157>.

To: <sip:5219848071234 at 70.99.100.101 <sip%3A5219848071234 at 70.99.100.101>
>;tag=as59051861.

User-Agent: SJphone/1.60.299a/L (SJ Labs).





On Tue, Mar 3, 2009 at 7:00 PM, Kobi Eshun <kobi at sightspeed.com> 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090303/b3e870e4/attachment-0001.htm 


More information about the Users mailing list