loose routing question

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

loose routing question

Brett Nemeroff
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Kobi Eshun
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


On Mar 3, 2009, at 4:41 PM, Brett Nemeroff wrote:

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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Brett Nemeroff
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 [hidden email] 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@208.124.125.126:5060>.

Call-ID: [hidden email].

Content-Type: application/sdp.

CSeq: 1 INVITE.

From: "unknown"<[hidden email]>;tag=34708247451729444157.

Max-Forwards: 69.

To: <[hidden email]>.

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 [hidden email] 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: [hidden email].

CSeq: 1 ACK.

From: "unknown"<[hidden email]>;tag=34708247451729444157.

Max-Forwards: 69.

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

To: <[hidden email]>;tag=as59051861.

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





On Tue, Mar 3, 2009 at 7:00 PM, Kobi Eshun <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Iñaki Baz Castillo
In reply to this post by Brett Nemeroff
2009/3/4 Brett Nemeroff <[hidden email]>:
> Question...
> In general the receipient of an INVITE should respond to that invite to the
> address in the contact header, right?

Not exactly. With "respond" you mean reply to a request? or new
in-dialog request sent by the callee?
- SIP replies must arrive to the UAC using the info in Via header (or
the existing TCP connection in case of TCP).
- SIP in-dialog requests must travel through all the proxies that did
loose-routing during the *FIRST* INVITE. This is, the Record-Route
headers that both the UAC and UAS receive (in the 200 Ok and in the
INVITE).


> What if there is a record-route header? That should prevail, right?

ACK for a INVITE-200 is a *new* transaction (so a new in-dialog
request) so it must be sent using the route set (Record-Route URI's
received in the 200 OK in reverse order).


> 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?

As you said, aproxy shouldn't add Record-Route in an in-dialog request
(re-INVITE). Anyway, if a UAS receives an in-dialog request with
Record-Route it MUST ignore these headers sice route set it just
defined during the initial INVITE.

You are doing nothing wrong, even if your proxy adds Record-Route in
in-dialog requests or not, it doesn't matter.

I would suggest you to do a good ngrep capture and send it to your
provider, pointing also to the RFC 3261 sections speaking about
loose-routing and in-dialog requests.

Regards.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Bogdan-Andrei Iancu
In reply to this post by Brett Nemeroff
Hi Brett,

As Inaki said, the Route header has priority over the Contact in
building the route set. You can check the Admin Course:

    http://www.voice-sistem.ro/downloads/2007.08.29-Admin-Course/

section 02 - routing. I put there a detailed description of  SIP routing
(and how RR works). If the archive contains only PDF file (with no
animation), just let me know and I can provide the PPT files.

Regards,
Bogdan

Brett Nemeroff wrote:

> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Robert Dyck
As an aside, there are Asterisk machines out there that do not follow the
rules. Specifically they will alter their route set according to R-R received
in-dialog. This usually does not cause a problem because most UA's repeat
their R-R in the in-dialog request. Twinkle as one example however does not
send R-R with the in-dialog request. Asterisk will then create a null route
set. Asterisk was patched I believe about a year ago for this problem but
service providers are slow to upgrade. I eventually gave up badgering one
service provider.

On Wednesday 04 March 2009, Bogdan-Andrei Iancu wrote:

> Hi Brett,
>
> As Inaki said, the Route header has priority over the Contact in
> building the route set. You can check the Admin Course:
>
>     http://www.voice-sistem.ro/downloads/2007.08.29-Admin-Course/
>
> section 02 - routing. I put there a detailed description of  SIP routing
> (and how RR works). If the archive contains only PDF file (with no
> animation), just let me know and I can provide the PPT files.
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
> > 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
> > [hidden email]
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Bogdan-Andrei Iancu
Hi Robert,

This is a typical example of "SIP understanding outside the SIP spec" :D..

RFC3261 is very clear that in a Route Set (RR headers and contact),
across the dialog, only the contacts can be changed. The RR headers
cannot be changed at all. So, no  UAC/UAS should look for RR headers in
any sequential request.

But the difference between theory and practice is that in theory, theory
and practice are the same, but in practice they are not.

So, to be on the safe side (at least from your point of view) is will be
better to do RR for sequential requests also - if the UAC/UAS are RFC
compliant, they will ignore it. If they don't, you try to set the same
Routing Set as per initial request.

Regards,
Bogdan

Robert Dyck wrote:

> As an aside, there are Asterisk machines out there that do not follow the
> rules. Specifically they will alter their route set according to R-R received
> in-dialog. This usually does not cause a problem because most UA's repeat
> their R-R in the in-dialog request. Twinkle as one example however does not
> send R-R with the in-dialog request. Asterisk will then create a null route
> set. Asterisk was patched I believe about a year ago for this problem but
> service providers are slow to upgrade. I eventually gave up badgering one
> service provider.
>
> On Wednesday 04 March 2009, Bogdan-Andrei Iancu wrote:
>  
>> Hi Brett,
>>
>> As Inaki said, the Route header has priority over the Contact in
>> building the route set. You can check the Admin Course:
>>
>>     http://www.voice-sistem.ro/downloads/2007.08.29-Admin-Course/
>>
>> section 02 - routing. I put there a detailed description of  SIP routing
>> (and how RR works). If the archive contains only PDF file (with no
>> animation), just let me know and I can provide the PPT files.
>>
>> Regards,
>> Bogdan
>>
>> Brett Nemeroff wrote:
>>    
>>> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>      
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>    
>
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Iñaki Baz Castillo
In reply to this post by Robert Dyck
2009/3/4 Robert Dyck <[hidden email]>:

> Twinkle as one example however does not
> send R-R with the in-dialog request.

Hi, no one SIP device sends R-R, neither in initial INVITE or
re-INVITE. R-R (Record-Route) must be add just be proxies, and UAS
must copy them in the 1XX/2XX responses to the *initial* INVITE.
When creating an in-dialog request, the SIp device must insert Route
headers, no Record-Route.


> Asterisk will then create a null route set.

I assume you mean that the *proxy* doesn't add R-R for in-dialog
request (the correct behaviour) so Asterisk fails and re-set the route
set.


Regards.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Robert Dyck
I did not describe the scenario accurately. I should have reviewed the issue
before composing my response.

The problem arises when the asterisk does a re-INVITE. If the UA receiving the
re-INVITE includes the original R-R list in the 200OK then asterisk will
route the ACK correctly. If the UA does not include the R-R list in the 200OK
the asterisk will create a null routeset and the ACK will be misrouted. The
spec says that a UAS may include R-R in the in-dialog response but the UAC
must ignore it. The same logic suggests that the lack of R-R should not be
interpreted as a null route set.

I am sorry about the confusion. You are quite right. The UA does not send a
R-R in a request.

On Thursday 05 March 2009, Iñaki Baz Castillo wrote:

> 2009/3/4 Robert Dyck <[hidden email]>:
> > Twinkle as one example however does not
> > send R-R with the in-dialog request.
>
> Hi, no one SIP device sends R-R, neither in initial INVITE or
> re-INVITE. R-R (Record-Route) must be add just be proxies, and UAS
> must copy them in the 1XX/2XX responses to the *initial* INVITE.
> When creating an in-dialog request, the SIp device must insert Route
> headers, no Record-Route.
>
> > Asterisk will then create a null route set.
>
> I assume you mean that the *proxy* doesn't add R-R for in-dialog
> request (the correct behaviour) so Asterisk fails and re-set the route
> set.
>
>
> Regards.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: loose routing question

Iñaki Baz Castillo
El Jueves, 5 de Marzo de 2009, Robert Dyck escribió:

> I did not describe the scenario accurately. I should have reviewed the
> issue before composing my response.
>
> The problem arises when the asterisk does a re-INVITE. If the UA receiving
> the re-INVITE includes the original R-R list in the 200OK then asterisk
> will route the ACK correctly. If the UA does not include the R-R list in
> the 200OK the asterisk will create a null routeset and the ACK will be
> misrouted. The spec says that a UAS may include R-R in the in-dialog
> response but the UAC must ignore it. The same logic suggests that the lack
> of R-R should not be interpreted as a null route set.
>
> I am sorry about the confusion. You are quite right. The UA does not send a
> R-R in a request.

Ok, I understand now what you mean. It's really an annoying bug in Asterisk
(but fixed now).

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users