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
