[SR-Users] Re-invites from carrier breaks the call

[Alex Balashov]

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/