Subject: [sipcore] Source address cahnges in SIP

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Nov 2016 14:31:28 -0500

I am changing the subject since this is not about the SIP source address
selection any more.

On Tue, Nov 8, 2016 at 3:38 AM, Asveren, Tolga <[email-masked]>
wrote:

> I am surprised that calls fail because of IP address migration. This seems
> to be more of an application issue rather than related with the SIP
> protocol. SIP has retransmissions for transactions. I think applications
> need to be updated/corrected for the scenarios you mention.
>
>
>
SIP has re-transmission for transactions but a lot of state full SIP
transactions implementations will not update the via header between
re-transmissions. So, if original message is sent from one IP and
re-transmission from another, response to the re-transmission will go the
the original IP/port.

Another interesting error case is when SIP over TCP or TLS is used and IP
address changes when SIP message is in flight. TCP connection is reset, but
it is unclear if SIP message was delivered to the server. Also, server has
no active TCP connection to send back the response.

Both of those situations in combination with SIP Session Timers can cause
calls to fail.

Finally, there is a situation when server needs to send a SIP Session timer
message to the client, but client IP have changed and client have not
detected this change yet. In such cases, server need to lookup client IP/port
based on GRUU in contact on every re-transmit.
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 9 Nov 2016 09:21:10 +0000

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.
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.
iii-  For SIP Session Timers: They usually are set on a value much higher than transaction timeout values.

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

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, November 08, 2016 2:31 PM
To: Asveren, Tolga <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: [sipcore] Source address cahnges in SIP

I am changing the subject since this is not about the SIP source address selection any more.

On Tue, Nov 8, 2016 at 3:38 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
I am surprised that calls fail because of IP address migration. This seems to be more of an application issue rather than related with the SIP protocol. SIP has retransmissions for transactions. I think applications need to be updated/corrected for the scenarios you mention.

SIP has re-transmission for transactions but a lot of state full SIP transactions implementations will not update the via header between re-transmissions. So, if original message is sent from one IP and re-transmission from another, response to the re-transmission will go the the original IP/port.

Another interesting error case is when SIP over TCP or TLS is used and IP address changes when SIP message is in flight. TCP connection is reset, but it is unclear if SIP message was delivered to the server. Also, server has no active TCP connection to send back the response.

Both of those situations in combination with SIP Session Timers can cause calls to fail.

Finally, there is a situation when server needs to send a SIP Session timer message to the client, but client IP have changed and client have not detected this change yet. In such cases, server need to lookup client IP/port based on GRUU in contact on every re-transmit.
_____________
Roman Shpount