The other possible solution that I can think of is sending 180 or 183 reliably when UAS receives an INVITE. This should ensure the UAC to stop Timer A. UAS must not send 200 OK unless UAS is sure that 1XX was received. I may be missing something.
Regards Ranga --- Roman Shpount <[EMAIL PROTECTED]> wrote: > My solution is a bit different. I do not terminate > server transaction when I send the 2XX response. I > move this transaction into a different state and > start a timer, which is set to fire in T4. If I > receive an INVITE message which matches the server > transaction in this state, I ignore it. This seems > to be more consistent with the way SIP transaction > state machines operate. > > This being said, this way of handling the INVITE > re-transmits is not standard. It looks like the RFC > says, that INVITE should be handled as a new call. I > don't think this is intended. I am sure multiple > ways can be designed to correct this. I am just > trying to make sure that I am not missing something > which is already in the standard or that I did not > stumble into a known problem. > > 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 > > ------ Original message ------ > > >From: Attila Sipos <[EMAIL PROTECTED]> > >Subject: RE: Re: [Sip-implementors] Problem with an > intial SIP INVITE servertransaction. > >Date: 17 Aug 04, 05:16 PM > >To: Roman Shpount <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > > > Hi Roman, > > As someone said, you could try matching up using > other SIP message components. > > For example, you could use the Call-ID: > > >From RFC3261: > >> Call-ID contains a globally unique identifier > for this call, > >> generated by the combination of a random string > and the softphone's > >> host name or IP address. The combination of > the To tag, From tag, > >> and Call-ID completely defines a peer-to-peer > SIP relationship > >> between Alice and Bob and is referred to as a > dialog. > > also: > >> Use of cryptographically random identifiers > (RFC 1750 [12]) in the > >> generation of Call-IDs is RECOMMENDED. > Implementations MAY use the > >> form "[EMAIL PROTECTED]". Call-IDs are > case-sensitive and are simply > >> compared byte-by-byte. > > > So, a call-ID for each new call should be unique (as > defined above) > so use this to as a check.If you see the same > call-ID again for > an INVITE with a CSeq that you have already received > then you > know it's a re-transmission and not an INVITE for a > new call. > > > For example: > (originator) > SIP INVITE--------------> > CSeq: 72334 INVITE > Call-ID: 9324uiwerkgn-283247-IUDBF893J-DDF (make > this nice and long) > > <-------------------100 Trying > <-------------------200 OK > > Now, even if the "100 Trying" and "200 OK" don't get > back > to the originator, when the re-transmitted INVITE > gets sent, the CSeq and Call-ID will be the same as > before > so the called party knows that it's a retransmission > and > will treat is such - it won't be treated as a new > call. > > So, if an INVITE is really a new one, the call-ID > would be different > (since it should be globally unique) and since the > CSeq is usually > random (for the first INVITE in a new call), this > would > probably be different too. You can't really rely on > the > CSeq being different but you could check it anyway. > > You should check other fields too: > 1. the INVITE should have a "From-tag" that you can > check. > (the From-tag should also be unique) > 2. you can check the branch (should also be unique) > in the Via > of the INVITE > 3. check the To and From (excluding tags) > 4. And once the to-tag and from-tag have been > exchanged, you can > check these too. > > Does this help? > > Cheers, > > Attila > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Roman > > Shpount > > Sent: 17 August 2004 16:53 > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: Re: [Sip-implementors] Problem with > an intial SIP INVITE > > servertransaction. > > > > > > Hi All, > > > > It looks like you are all missing the point. The > fact that > > server transaction sent the 100 and 2XX responses > in no way > > means that UA cannot receive the re-transmitted > INVITE > > message. If you look at majority of the > transaction state > > machines in SIP you will see, that they are > designed to > > handle messages, that are received after the > response is > > sent. It is not unconceivable, in my scenario, > that 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. The problem is not with the > implementation, there > > seems to be a problem with the RFC, unless I am > missing > > something. What I am looking for, is a standard > compliant way > > of dealing with this situation. > > ___________________________________ > > Roman Shpount, VP of Technology > > aTelo, Inc. -- www.atelo.com > > > > ------ Original message ------ > > > > >From: SiM <[EMAIL PROTECTED]> > > >Subject: Re: [Sip-implementors] Problem with an > intial SIP > > INVITE server transaction. > > >Date: 17 Aug 04, 01:49 PM > > >To: <[EMAIL PROTECTED]> > > >Cc: Roman Shpount <[EMAIL PROTECTED]> > > > > Hi Roman, > > From your description it looks > like , the > > responses to the INVITE are not getting matched to > the ICT at > > the UAC. Hence the Server closes the transaction > when it > > sends a 200 OK , but the UAC is still > retransmitting as it > > has not got any valid response which is matching > it's transaction. > > But, if you are talking about > the case > > where the 1xx is lost and the 2xx and INVITE are > over === message truncated === __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
