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]>INVITE server transaction.
Subject: Re: [Sip-implementors] Problem with an intial SIP
Date: 17 Aug 04, 01:49 PMHi Roman,
To: <[EMAIL PROTECTED]>
Cc: Roman Shpount <[EMAIL PROTECTED]>
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
