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
