Anil,

The presence of same call-id, cseq, branch-id in vias should be
enough to indicate that it is a retransmitted INVITE rather than a 
forked INVITE or a new INVITE.

On receiving an INVITE on UAS typically the "software" looks up the 
CALLID to check if there is a call(dialog) with that CALLID. if there 
is a dialog with that callid, then you look at the from-tag (different
from tag should instantly be flagged as an error), branchid, cseq number 
etc to verify that it is not a forked invite or a re-invite(if to-tag 
present). Given that it does not meet the above three conditions : 
it is not a INVITE on an INVALID call, it is not a forked INVITE,
it is not a re-INVITE, it is treated as a retransmitted INVITE)

On the otherhand, on a stateless proxy such a retransmitted INVITE
needs to be forwarded towards the UAS since it does not have the
context to interpret the message.

thanks
Arun Punj
ViPr Principal Engineer
Broadband Routing & Switching

Marconi
3000 Marconi Drive
Warrendale, PA 15086

Phone: 724-742-7583
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>



> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Anil
> Bollineni
> Sent: Thursday, May 26, 2005 6:29 PM
> To: [email protected]; [email protected]
> Subject: [Sip-implementors] About Invite Server transaction
> 
> 
> Hi, 
> 
>             Assume 100, 200 responses are sent from UAS to client, and
> they are lost. Then INVITE is retransmitted to UAS. As soon 
> as UAS send
> 200 OK it destroys the server transaction. Per UAS, the 
> dialog state is
> already created after sending 200 response. If INVITE is passed to TU
> from transport layer, then how this INVITE is been treated as
> retransmission of INVITE, since the TU, will  not able to match any
> existing dialog (since no to-tag in INVITE), and will it 
> treat as a new
> call. Is the assumption correct? Or where in RFC this scenario will be
> treated.
> 
>  
> 
> Thanks,
> 
> Anil
> 
> _______________________________________________
> 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

Reply via email to