Subject: Re: [sipcore] Source address changes in SIP

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Nov 2016 19:58:24 -0500

On Wed, Nov 9, 2016 at 4:21 AM, Asveren, Tolga <[email-masked]>
wrote:

> i- If a transaction fails, it is application’s responsibility to do the
> right thing –whatever that is based on the expected outcome-, e.g. sending
> a new request.
>

What happens on most of the clients if SIP Session timer refresh
transaction fails? Form what I know, typically the call is torn down.

> ii- For the TCP scenario you mentioned, it is again up to the application
> to send a new request just to be sure that it has been received.
>

For TCP sending the same request for an existing transaction over a new
flow can produce "interesting" results. In most cases response will be sent
to via address and port from the original transaction, which are ephemeral.
Plus the RFC says that message sent over TCP should be re-transmitted.

> iii-  For SIP Session Timers: They usually are set on a value much higher
> than transaction timeout values.
>

It does not matter what SIP Session timer value is. If SIP Session timer
refresh transaction fails, the whole call normally fails.

> Overall, I don’t think there is a serious SIP protocol level issue here,
> which is causing pain in practice.
>
>
>
Actually, as far as I know, there are at least two SIP protocol level
issues here:

1. Handling of client IP change in the middle of transaction is not
specified anywhere.
2. Handling of TCP connection tear down in the middle of transaction is not
specified anywhere. Handling of SIP responses when client TCP connection
was torn down in RFC 3621 (sending to received/port from VIA over TCP) does
not work unless client is on public IP.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 13 Nov 2016 09:56:22 +0000

Although “RFC4028 10 Performing Refreshes” mentions about terminating the session if the session refresh transaction times out no normative keywords are used. I also do not think trying a new session refresh request would break anything from protocol machinery perspective. I would think that a prudent application would do so if there is the possibility of IP Address change – or some other reason for retry -.

The TCP case is similar, if the deployment model/practical reality makes it possible that TCP connection can be broken even if the peer is still alive, an application better uses retransmission for TCP as well. Actually, this is widely implemented in many products. Please note that establishing a TCP connection toward UE behind NAT would not be possible for most of the cases even if the network-side equipment uses the “right” IP Address/port. Most NATs wouldn’t allow inbound TCP connection establishment requests.

Overall, all these seem to me more issues to be dealt with by applications. IMHO it could be an idea to provide some guidance about them in a “Best Practices” document though.

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Wednesday, November 09, 2016 7:58 PM
To: Asveren, Tolga <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Source address changes in SIP

On Wed, Nov 9, 2016 at 4:21 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
i- If a transaction fails, it is application’s responsibility to do the right thing –whatever that is based on the expected outcome-, e.g. sending a new request.

What happens on most of the clients if SIP Session timer refresh transaction fails? Form what I know, typically the call is torn down.

ii- For the TCP scenario you mentioned, it is again up to the application to send a new request just to be sure that it has been received.

For TCP sending the same request for an existing transaction over a new flow can produce "interesting" results. In most cases response will be sent to via address and port from the original transaction, which are ephemeral. Plus the RFC says that message sent over TCP should be re-transmitted.

iii-  For SIP Session Timers: They usually are set on a value much higher than transaction timeout values.

It does not matter what SIP Session timer value is. If SIP Session timer refresh transaction fails, the whole call normally fails.

Overall, I don’t think there is a serious SIP protocol level issue here, which is causing pain in practice.

Actually, as far as I know, there are at least two SIP protocol level issues here:

1. Handling of client IP change in the middle of transaction is not specified anywhere.
2. Handling of TCP connection tear down in the middle of transaction is not specified anywhere. Handling of SIP responses when client TCP connection was torn down in RFC 3621 (sending to received/port from VIA over TCP) does not work unless client is on public IP.

Regards,
_____________
Roman Shpount