Subject: Re: [sipcore] sip/tcp with primary & secondary outbound

From: "Penar, Russell" <[email-masked]>
Date: Tue, 26 Jan 2016 20:39:26 +0000

Thank you Paul,
I am aware and somewhat familiar with 5626, largely for the Keep-Alive content.
I'm missing the details in 5626 addressing the TCP/RST issue for an HA proxy as I described.

3.3 gets close with a possible solution, however in practice UAs I encounter have a single outbound proxy field and don't support dual registration paths.  If they did, I believe my scenario is still an issue given most commercial proxies are stateful b2bua's (SBCs) and the second path won't recognize the session re-Invite as valid.
Regards,
Russ

-----Original Message-----
----------------------------------------------------------------------
Date: Tue, 26 Jan 2016 11:30:52 -0500
From: Paul Kyzivat <[email-masked]>
To: [email-masked]
Subject: Re: [sipcore] sip/tcp with primary & secondary outbound
        proxies (behavior upon receipt of tcp rst)
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Russ,

Are you aware of RFC5626? It provides an explicit mechanism for redundant registration paths.

        Thanks,
        Paul

On 1/25/16 6:23 PM, Penar, Russell wrote:
> Thanks for the reply Dale, comments in line.
> Regards,
> Russ
>
> -----Original Message-----
> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Monday, January 25, 2016 1:23 PM
> To: Penar, Russell
> Cc: [email-masked]
> Subject: Re: [sipcore] sip/tcp with primary & secondary outbound
> proxies (behavior upon receipt of tcp rst)
>
> "Penar, Russell" <[email-masked]> writes:
>> I'm seeing non-ideal behavior from cpe and hoping this group can
>> provide guidelines specific to the scenario below, and ultimately
>> standardize ideal cpe behavior for the given context.  I haven't
>> found any specifications defining the ideal behavior, and it was
>> suggested during sipnoc to contact sipcore as an appropriate next step.
>
> Unfortunately, Sipcore doesn't so much define ideal behavior as define the behaviors that a UA (CPE) is permitted to have.  Within that context, a UA can drop a call whenever it chooses.  In the use cases we see, the general advice is "If the UA is behaving in a way that provides a poor user experience, buy a different type of UA."  That usually gives the UA manufacturers incentive to improve their UAs.
>
> RP - That's a fair stance, we have seen at least one vendor move to the "ideal" behavior presumably from customer pressure.  Would it also be fair to state Sipcore defines behavior that a UA is not permitted to have?  Perhaps what I'm really trying to get here is a MUST NOT statement against connecting to secondary targets upon receipt of a TCP RST.
>
>> Where a standing call is setup against the primary sbc; after a
>> primary sbc mated pair failover, calls are at risk of being dropped
>> if a tcp connection is not established back to the primary sbc.  This
>> can be due to session audits from the platform, or more specific to
>> my ask is a cpe re-Invite scenario.  For example, when cpe puts
>> standing call on hold (after sbc failover), the sbc target for
>> re-establishing the signaling tcp session is critical.
>>
>> I've seen cpe exhibit ideal behavior, where upon receipt of tcp rst
>> the cpe connects back to the primary sbc.  In that ideal scenario,
>> the call stays up, mid-call control doesn't fail, etc.  And I've seen
>> non-ideal behavior where once the cpe attempts to put the call on
>> hold, it reacts to the tcp rst by failing over to the secondary sbc
>> and dropping the standing call.  Fwiw, I'm told the vendor exhibiting
>> the ideal behavior only recently began to do so (reportedly from
>> customer pressure to properly support geo-redundant setups as
>> described above).
>
> As a general rule, the failure of a TCP connection does not change the state of any SIP call.  But if the UA wants to issue a re-INVITE for an existing call, it will send an INVITE request using the "route set" of the call.  The UA learns the route set during call set-up; the devices on the path that the INVITE request takes will add Record-Route or Contact headers containing addresses; the collection of these headers is the route set and specifies the path which all further requests for that call will take.
>
> Since the SBC wants to see further requests for the call, it adds an address for itself in either a Record-Route header or a Contact header (depending on the technical details of the SBC).  If you want the calls to fail over, it's critical that the address is one that routes to both the primary and secondary SBCs -- it is a host name which DNS maps to the addresses of both SBCs.
>
> RP - We're using DNS SRV to support geo-redundant access SBCs.  The "route set" doesn't appear to be an issue, as the re-Invite does go to the correct location (primary), but upon receipt of the TCP RST the UA immediately drops the call, sets up a new TCP connection to the secondary and Registers.  The UA gathers primary and secondary targets (for outbound proxy FQDN) upon boot up and then accordingly based on TTL.
>
> If the address is only for the SBC involved in the call setup, if that SBC goes down and the UA attempts a re-INVITE, the UA can't send the re-INVITE.  The UA may decide to tear down the call, but some UAs don't -- instead, they assume that if the call truly fails, the user will hang up and so they maintain the call until the user hangs up.
>
> RP - I agree in principle when using SRV the SBC's Contact/R-R should have the SBC FQDN and not a specific IP address.  With use of outbound proxy, I haven't seen issues with UA's not failing over when Contact (for example) is returned with only the SBC (HA pair IP address) involved in the call setup.
>
> It's understood that if a UA attempts to send a request on a TCP connection and the TCP connection produces some sort of error that the UA should either attempt to reestablish the TCP connection or send the request to an alternative destination (e.g., the other SBC).  This is specified in RFC 3263 section 4.3:
>
>     For SIP requests, failure occurs if the transaction layer reports a
>     503 error response or a transport failure of some sort (generally,
>     due to fatal ICMP errors in UDP or connection failures in TCP).
>     Failure also occurs if the transaction layer times out without ever
>     having received any response, provisional or final (i.e., timer B or
>     timer F in RFC 3261 [1] fires).  If a failure occurs, the client
>     SHOULD create a new request, which is identical to the previous, but
>     has a different value of the Via branch ID than the previous (and
>     therefore constitutes a new SIP transaction).  That request is sent
>     to the next element in the list as specified by RFC 2782.
>
> RP - Could we amend this section of 3263, to reflect a UA SHOULD (specific to context of TCP) try the current element where a SIP dialog is established before trying the next element per 2782?
>
> Dale
>
> This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.