Subject: Re: [Sip] Problem with an intial SIP INVITE server transa ction.

From: Gautham <[email-masked]>
Date: Mon, 27 Sep 2004 19:48:24 +0530

Hi,

The scenario given by Roman could happen at either a proxy or a endpoint.

At a proxy, the appropriate thing would be to create a new transaction.
Like Roman has mentioned in his mail, this retransmission may be because 
the
1xx responses and the 2xx responses were lost. In such a case,  I believe,
it would be correct for the proxy to create a new transaction and
forward the INVITE downstream, as if it were a new transaction.
In anycase,  a proxy would not know better.

At an endpoint too, it should not be a problem if a new server 
transaction gets created
for the retransmitted INVITE. The UA core can look at the From  tag, 
Call-Id and possibly CSeq
to determine that it is not a new dialog request i.e., that it matches 
an ongoing dialog.
If the UA core is still retransmitting the 2xx, it would send the 2xx to 
the
transaction which would terminate it. If the UA core has finished 
retransmitting
the 2xx (and has received the ACK) it could treat the INVITE as an
out-of-sequence request.

Hope this helps.

Regards,
A. N. Gautham

Paul D.Smith wrote:

>Roman,
>
>I believe you have strayed into a poorly specified area of SIP here.  I have
>also found nothing in the specs. that directly answers your question however
>I can tell you what is observed:  the duplication INVITEs are simply
>ignored.  One option is to keep track of the INVITE transaction until the
>ACK arrives.  Although logically there is no transaction layer interaction
>(as per section 17, RFC 3261), you can then identify the INVITE as a
>duplicate and discard it.
>
>Paul D Smith
>Network Protocols Group 
>Data Connection Ltd (DCL)
>Tel: +44 20 8366 1177  Email: [email-masked] 
>Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com
>
>
>-----Original Message-----
>From: Roman Shpount [mailto:[email-masked]]
>Sent: 19 September 2004 08:15
>To: SIP Public Folder (E-mail)
>Subject: Re: RE: RE: [Sip] Problem with an intial SIP INVITE server
>transaction.
>
>
>Thomas,
>
>The problem is that retransmitted INVITE message does not have the To-tag.
>Thus it does not match the dialog and UAC is not even informed about this
>message. The only way I could think to deal with this, as I described in my
>original email, was to add a timer which keeps the server INVITE transaction
>open for T4 after 2XX response is sent. If retransmitted INVITE message
>arrives within this time, it matches the transaction and is ignored. By the
>way, this discussion is not academic, this is the real problem that we
>encountered while dealing with large volumes of SIP transactions over Wi-Fi.
>___________________________________
>Roman Shpount, VP of Technology
>aTelo, Inc. -- www.atelo.com
>
>------ Original message ------
>
>  
>
>>From: Thomas Gal <[email-masked]>
>>Subject: RE: RE: [Sip] Problem with an intial SIP INVITE server
>>    
>>
>transaction.
>  
>
>>Date: 31 Aug 04, 04:44 PM
>>To: 'Roman Shpount' <[email-masked]>,  <[email-masked]>,
>>    
>>
><[email-masked]>
>
>Maybe some people were just trying to help without scouring the spec for all
>the details. I have read the spec quite a few times, thanks, but here, maybe
>this will help(17):
>
>	In the case of a transaction where the
>   request was an INVITE (known as an INVITE transaction), the
>   transaction also includes the ACK only if the final response was not
>   a 2xx response.  If the response was a 2xx, the ACK is not considered
>   part of the transaction.
>
>      The reason for this separation is rooted in the importance of
>      delivering all 200 (OK) responses to an INVITE to the UAC.  To
>      deliver them all to the UAC, the UAS alone takes responsibility
>      for retransmitting them (see Section 13.3.1.4), and the UAC alone
>      takes responsibility for acknowledging them with ACK (see Section
>      13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is
>      effectively considered its own transaction.
>
>You gotta wait til you get the ACK.
>
>-Tom
>
>
>-----Original Message-----
>From: Roman Shpount [mailto:[email-masked]] 
>Sent: Tuesday, August 31, 2004 8:38 AM
>To: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: RE: [Sip] Problem with an intial SIP INVITE server transaction.
>
>Hi All, 
>
>I got quite a few answers like: "there is a magic key which prevents this"
>or "there is a timer that prevents this", or "you cannot get an INVITE once
>you sent the 1XX or 2XX response". I would suggest that you would read the
>RFC (Section 17.2.1) before rushing to answer my question. RFC clearly
>spells out that INVITE server transaction is terminated when 2XX response is
>sent. There is even a picture (Figure 7) that shows just that. There are no
>timers. There are no special transaction IDs. Transaction is ended, clear
>and simple. Once transaction is ended, re-transmitted INVITE message should
>start the new transaction.  
>___________________________________
>Roman Shpount, VP of Technology
>aTelo, Inc. -- www.atelo.com
>
>------ Original message ------
>
>  
>
>>From: Gordon Ledgard <[email-masked]>
>>Subject: RE: [Sip] Problem with an intial SIP INVITE server transaction.
>>Date: 31 Aug 04, 12:40 PM
>>To:  <[email-masked]>, Roman Shpount <[email-masked]>,  
>><[email-masked]>
>>    
>>
>
>
>Read the stuff about timers in the transaction layer. It spells out how you
>need to hold on to transactions for messages over unreliable transports for
>just this sort of reason.
>
>
>Gordon
>
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of Thomas
>Gal
>Sent: Monday, August 30, 2004 7:54 PM
>To: 'Roman Shpount'; [email-masked]
>Subject: RE: [Sip] Problem with an intial SIP INVITE server transaction.
>
>
>I'm not an expert on this protocol (only read through the spec a few times
>so it blurs together with some of the other ones) but even without looking
>I'm SURE there's supposed to be a unique request-ID generated by the client
>to avoid just such a confusion. Of course in this case any stateful UA would
>ignore the already processed invite request. Also (sure about this one) if
>the client received the provisional(100) response it wouldn't re-transmit
>the INVITE either as that's the whole point.
>
>-Tom
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman
>Shpount
>Sent: Tuesday, August 17, 2004 7:05 PM
>To: [email-masked]
>Subject: [Sip] Problem with an intial SIP INVITE server transaction.
>
>I run into the problem with handling of retransmitted SIP INVITE message
>based on the RFC 3621. 
>
>Imagine the following situation
>
>INVITE 1
>----------------------->
>100
><-----------------------
>2XX
><-----------------------
>re-transmitted INVITE 1
>----------------------->
>
>Based on RFC 3261, server INVITE transaction terminates as soon as 2XX
>response is sent. This means that re-transmitted INVITE will be treated as a
>new transaction. This INVITE message will not match the existing dialog,
>since its To tag is empty. This means it will be treated as new dialog
>creating message and phone will treat this message as a new call, which is
>clearly not intended.
>
>This situation can occur if both 100 and 2XX responses were lost by the
>unreliable transport, and INVITE continues to be re-transmitted. The fact
>that, 100 and 2XX responses were lost is unknown to the server transaction
>and INVITE re-transmit can arrive before the 2XX re-transmit is sent. 
>
>Majority of the transaction state machines in SIP are designed to handle
>messages, that are received after the response is sent. It seems that
>something simular is required in this case as well. 
>
>In our implementation of SIP stack, server transaction is not terminated
>when the 2XX response is sent. Instead, transaction is moved into the
>"ConfirmedBis" state and timer, which is set to fire in T4, is started. If
>the stack receives an INVITE message which matches the server transaction in
>this state, it ignores it. If stack receives a 2XX response, which matches
>the server transaction, it passes it to TU. Once the T4 timer is fired, the
>transaction is terminated.
>
>There is also an additional issue related to this problem. It looks like,
>for the sake of consistency, some type of response should be sent
>immediately to the transport layer when INVITE re-transmit is received. If
>multiple 2XX responses has been sent, it is unclear what the behavior should
>be: should all the 2XX messages be sent, should the last 2XX message be
>resent or should the INVITE be plainly ignored. 
>
>___________________________________
>Roman Shpount, VP of Technology
>aTelo, Inc. -- www.atelo.com
>
>
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use
>[email-masked] for questions on current sip Use
>[email-masked] for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol Use
>[email-masked] for questions on current sip Use
>[email-masked] for new developments on the application of sip
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip
>
>  
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Roman Shpount <[email-masked]>
Date: 27 Sep 2004 15:50:40 GMT

I do not belive this will work. In case of proxy it can route this INVITE message to a completely different endpoint, then it did for the first INVITE. This means that a new dialog will be established, which is clearly not intended

As far as SIP UA is concerned, this will also not work, for one very simple reason -- SIP INVITE does not match the SIP dialog. If we want to create a mechanism to match this INVITE to an existing dialog, this mechanism should be part of the standard. Furthermore, it would be a very bad thing to create a new transaction for the re-transmitted INVITE. Imagine, what would the SIP UA, that originated the call do if it receives two responses, one successful and one failure in unspecified order. If SIP UA will receive the failure or out of order response first, it will ignore all the success responses afterwards. I am not even sure what SIP UA will do if it receives a failure response after the success. I do not belive this is even allowed.

As I mentioned before, the most consistent way of dealing with this scenario is to put a timer, which will keep the transaction going after 2XX response is sent. If transaction receives a message during this time, this message is ignored. 

As I mentioned before, I am not looking as much for the way to deal with this problem, as for the way to fix the RFC.
___________________________________
Roman Shpount, VP of Technology
aTelo, Inc. -- www.atelo.com

------ Original message ------

>From: Gautham <[email-masked]>
>Subject: Re: [Sip] Problem with an intial SIP INVITE server transa ction.
>Date: 27 Sep 04, 02:18 PM
>To: Paul D.Smith <[email-masked]>
>Cc: 'Roman Shpount' <[email-masked]>, SIP WG <[email-masked]>

Hi,

Hope this helps.

Regards,
A. N. Gautham