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

From: "Paul D.Smith" <[email-masked]>
Date: Fri, 24 Sep 2004 13:12:35 +0100

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