[SR-Users] Re-invites from carrier breaks the call
Will Ferrer
will.ferrer at switchsoft.com
Sat Feb 21 03:52:34 CET 2015
Hi Alex
Thanks for the great analyse, see my comments below. I will send you some
sip captures as well.
On Fri, Feb 20, 2015 at 4:53 PM, Alex Balashov <abalashov at evaristesys.com>
wrote:
> On 02/20/2015 07:39 PM, Will Ferrer wrote:
>
> Perhaps what I could do with the module is set a long minimum timeout,
>> long enough that it would allow our calls to complete before the
>> re-invite occurs. A messy solution but might work in a pinch.
>>
>
> Perhaps. But again, I would say you are solving the wrong problem
> entirely. :-) Your initial complaint was:
Hehe, yes, which is why I will start looking for a softphone that doesn't
have the issue, but since we can't guaranteed that all our clients use
compliant soft phones and networks I was hoping maybe a band aid would
suffice.
>
>
> "This causes the softphone to keep sending 200 oks since it
> never gets the ack.
>
> This is the REAL problem, and that's the problem that should be solved.
>
> To clarify:
>
> When an initial INVITE from A to B is routed through a record-routing
> proxy P, the proxy adds a Record-Route header containing its own IP address
> to the INVITE before relaying it. That is:
>
> INVITE sip:foo at B SIP/2.0
> ...
> Contact: <sip:myself at A:5060>
> Record-Route: <sip:P;lr=on>
>
> The UAS receiving this INVITE is supposed to copy this Record-Route
> header, verbatim, into the 200 OK response to that INVITE:
>
> SIP/2.0 200 OK
> ...
> Contact: <sip:me at B:5060>
> Record-Route: <sip:P;lr=on>
>
> This step causes the UAC that sent the initial INVITE to also be aware of
> the Record-Route set.
>
> Subsequent sequential (in-dialog requests having a to-tag) sent from
> EITHER party to the other, including end-to-end ACKs for 2xx responses,
> reinvites, BYEs, et cetera, MUST have the following attributes:
>
> 1) Route header whose value is equivalent to the Record-Route set added by
> the proxy, e.g.
>
> Route: <sip:P;lr=on>
>
The 200 ok from softphone after the second invite does not have a record
route for the softphone this what I thought was the problem but after
reading the rest of your post I think it's another issue entirely.
>
> 2) A request URI equal to the Contact URI of the counterparty, as declared
> in the initial INVITE and the final 2xx reply respectively. These are known
> as "remote targets" of the dialog, and can only be updated (although
> usually aren't) in reinvites.
>
Ah, well this piece of info points to another problem which may be the
actual issue. So what you are saying is that the final hop that ack makes
on it's way back should be made via the request uri of the ack. After
reading this I see that the request uri of the ack coming back from the
carrier is wrong. It has the outside of the softphone as it's target with
the alias of our sbc box.
Looking at what is happening I found the following:
1) The softphone sends an invite with the contact set to it's inside ip.
2) We send a correct contact with the inside ip of the phone and an alias
of the outside ip of the softphone. This gets through both our dispatcher
box and our call processing box out to the carrier.
3) All the messages looking good and latter down the line the carrier sends
back it's 200 ok.
4) This is where things start going down hill. Our softphone sends an ack,
but for some reason this ack has a contact header which contains just the
softphones outside ip, instead of it's inside ip as it did in the
softphones first invite.
5) The re invite comes in from the carrier, it's RURI looks good, pointed
at the softphone with the right alias.
6) Softphone sends a 200 ok, with just the outside ip of the softphone as
the contact (which is likely the cause of the problem).
7) Our call processing box mistakenly adds the ip of the dispatcher box to
the contact as the alias for the outside ip of the softphone and this gets
passed to the carrier.
8) The carriers RURI in the ack that has the outside of the softphone and
the dispatcher box as it's alias.
> They must also be sent to P on the network and transport level, regardless
> of the RURI.
>
> So, I assume that in your initial complaint,
>
> "When a reinvite occurs, our softphone client gets the
> invite, sends a 100, and then sends 200 ok. However the
> 200 ok does not have the softphones ip in the record route.
> Since it's not in the record route the ack from the carrier
> never makes it's way all the back to the softphone."
>
> ... you are lumping together the discussion of the _sequential_ reinvite
> with the 200 OK for the _initial_ INVITE. Thus, it is not correct to say
> that "When a reinvite occurs... the 200 OK does not have the softphone's IP
> in the Record-Route". It sounds like the answerer of the call isn't copying
> the Record-Route set into the final 2xx reply for the _initial_ INVITE
> transaction, leading the UAC to be unaware of it. The 200 OK for the
> _reinvite_ shouldn't have a Record-Route header. There should not be any
> Record-Route headers outside of the initial INVITE transaction flow
> (Record-Route != Route).
>
I had apparently mistakenly understood that the 200 ok needed to have the
softphone in the record route. The 200 ok coming from the softphone in
response to the second invite does have a record route header but it has
just the dispatcher box and the call processing box.
>
> This statement is also not a correct diagnosis:
>
> "the 200 ok does not have the softphones ip in the record route"
>
> ... nor should it. The proxy's IP, not the softphone's IP, should be in
> the Route set.
>
> -- Alex
>
>
It looks like I had misdiagnosed the problem and your well put together
explanation pointed me in the direction of what is likely the real problem.
I still don't know what to do for a solution however.
Thanks again for your in valuable assistance.
I hope this message finds you well.
Will
On Fri, Feb 20, 2015 at 4:53 PM, Alex Balashov <abalashov at evaristesys.com>
wrote:
> On 02/20/2015 07:39 PM, Will Ferrer wrote:
>
> Perhaps what I could do with the module is set a long minimum timeout,
>> long enough that it would allow our calls to complete before the
>> re-invite occurs. A messy solution but might work in a pinch.
>>
>
> Perhaps. But again, I would say you are solving the wrong problem
> entirely. :-) Your initial complaint was:
>
> "This causes the softphone to keep sending 200 oks since it
> never gets the ack.
>
> This is the REAL problem, and that's the problem that should be solved.
>
> To clarify:
>
> When an initial INVITE from A to B is routed through a record-routing
> proxy P, the proxy adds a Record-Route header containing its own IP address
> to the INVITE before relaying it. That is:
>
> INVITE sip:foo at B SIP/2.0
> ...
> Contact: <sip:myself at A:5060>
> Record-Route: <sip:P;lr=on>
>
> The UAS receiving this INVITE is supposed to copy this Record-Route
> header, verbatim, into the 200 OK response to that INVITE:
>
> SIP/2.0 200 OK
> ...
> Contact: <sip:me at B:5060>
> Record-Route: <sip:P;lr=on>
>
> This step causes the UAC that sent the initial INVITE to also be aware of
> the Record-Route set.
>
> Subsequent sequential (in-dialog requests having a to-tag) sent from
> EITHER party to the other, including end-to-end ACKs for 2xx responses,
> reinvites, BYEs, et cetera, MUST have the following attributes:
>
> 1) Route header whose value is equivalent to the Record-Route set added by
> the proxy, e.g.
>
> Route: <sip:P;lr=on>
>
> 2) A request URI equal to the Contact URI of the counterparty, as declared
> in the initial INVITE and the final 2xx reply respectively. These are known
> as "remote targets" of the dialog, and can only be updated (although
> usually aren't) in reinvites.
>
> They must also be sent to P on the network and transport level, regardless
> of the RURI.
>
> So, I assume that in your initial complaint,
>
> "When a reinvite occurs, our softphone client gets the
> invite, sends a 100, and then sends 200 ok. However the
> 200 ok does not have the softphones ip in the record route.
> Since it's not in the record route the ack from the carrier
> never makes it's way all the back to the softphone."
>
> ... you are lumping together the discussion of the _sequential_ reinvite
> with the 200 OK for the _initial_ INVITE. Thus, it is not correct to say
> that "When a reinvite occurs... the 200 OK does not have the softphone's IP
> in the Record-Route". It sounds like the answerer of the call isn't copying
> the Record-Route set into the final 2xx reply for the _initial_ INVITE
> transaction, leading the UAC to be unaware of it. The 200 OK for the
> _reinvite_ shouldn't have a Record-Route header. There should not be any
> Record-Route headers outside of the initial INVITE transaction flow
> (Record-Route != Route).
>
> This statement is also not a correct diagnosis:
>
> "the 200 ok does not have the softphones ip in the record route"
>
> ... nor should it. The proxy's IP, not the softphone's IP, should be in
> the Route set.
>
> -- Alex
>
>
>
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> United States
>
> Tel: +1-678-954-0670
> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150220/f838d887/attachment.html>
More information about the sr-users
mailing list