> What I meen to say is since rfc 3261 tells that you should match all of > Call-ID, From tag and To tag, some implementation may not concentrate > that much on generating a cryptographic Call-ID (Because anyway From tag > and To tag are also there), in which case retransmitted INVITE may be > given to the same dialogue.
I agree totally. Implementations shouldn't rely exclusively on the call-ID, I was just trying to show Roman one particular idea. Anyway, later in the e-mail, I did say that you should also check CSeq, To, to-tag, From, from-tag and the branch in the Via. So, I certainly wouldn't encourage heavy dependence on the Call-ID. Cheers, Attila > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Biplab > Chattopadhyay > Sent: 18 August 2004 16:53 > Cc: [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Problem with an intial SIPINVITE > servertransaction. > > > Hi Attila, > This seems to be a work around. But is not the solution too much > dependent on Call-ID? What if the other side, which may be any sip > implementation, is not generating Call-ID in that > sophisticated manner. > What I meen to say is since rfc 3261 tells that you should > match all of > Call-ID, From tag and To tag, some implementation may not > concentrate > that much on generating a cryptographic Call-ID (Because > anyway From tag > and To tag are also there), in which case retransmitted INVITE may be > given to the same dialogue. > > Cheers, > Biplab. > > Attila Sipos wrote: > > >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 the > >>wire at the same time , probably you should use some way to > >>detect such cases at the UAS, like the one Ranga suggests. > >> > >>Cheers. > >>Simith > >> > >> > >>Roman Shpount <[EMAIL PROTECTED]> wrote: > >>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. > >> > >>___________________________________ > >>Roman Shpount, VP of Technology > >>aTelo, Inc. -- www.atelo.com > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Sip-implementors mailing list > >>[EMAIL PROTECTED] > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > >>Yahoo! India Matrimony: Find your life partneronline. > >> > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Sip-implementors mailing list > >>[EMAIL PROTECTED] > >>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > >> > >> > > > >_______________________________________________ > >Sip-implementors mailing list > >[EMAIL PROTECTED] > >http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > -- > -------------------------------------------------------------- > -------------- > Biplab Chattopadhyay > Research Engineer > CDOT-Bangalore > email: [EMAIL PROTECTED] > [EMAIL PROTECTED] > Phone# > Office: 2263399, ext 255 > 2383951 (direct) > Mobile: 9845378867 > -------------------------------------------------------------- > -------------- > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
