Nasir,

The following should help you:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-race-examples-01.txt

        Paul

Nasir Khan wrote:
> With respect to the bug
> 
>  
> 
> http://bugs.sipit.net/show_bug.cgi?id=769
> 
>  
> 
> <snip>
> 
>  
> 
> The current text in 3261 instructs a UAS to destroy an INVITE
> transaction the
> 
> instant it sends a 200.
> 
>  
> 
> This has the unintended consequence that any retransmissions of the
> INVITE
> 
> request that arrive after that destruction will be treated as a new
> request.
> 
>  
> 
> This interacts both with endpoints and proxies (the deletion of the
> server
> 
> transaction combined with stateless forwarding of responses without
> matching
> 
> transactions provided forwarding of multiple 200s to forked INVITES).
> 
>  
> 
> The fix will involve having the server transaction continue to exist
> long
> 
> enough to drain any retransmissions of the INVITE and related changes to
> 
> the UAS handling of retransmitting the 200s, and proxies handling
> multiple
> 
> 200s/stray responses.
> 
>  
> 
> </snip>
> 
>  
> 
> Is the fix defined somewhere? 
> 
>  
> 
> Would the fix just be creating a new state say "Finished" that is
> entered when a 2xx response is sent and starts a new timer (Timer L
> perhaps?) which similar to Timer I is set to T4 for unreliable
> transports? 
> 
>  
> 
> Also if INVITE is retransmission is received in "Finished" state then
> would the Transaction re-send last response (2xx) or hand over the
> request to TU? I think it should re-send the last 2xx. 
> 
>  
> 
> ACK of course would not hit this transaction as it is an ACK for 2xx,
> but the Finished->Terminated transition should happen only on Timer (L
> ?) expiry. 
> 
>  
> 
> Can someone please comment on this?
> 
>  
> 
> Also in the bug report there is a mention of "and related changes to
> 
> the UAS handling of retransmitting the 200s, and proxies handling
> multiple
> 
> 200s/stray responses." 
> 
>  
> 
> Are these separate bugs? Is there any explanation of what is intended
> here?
> 
>  
> 
> Thanks
> 
> Nasir 
> 
>  
> 
> Discuss SIP Servlets at http://groups.google.com/group/sipservlets/
> <http://groups.google.com/group/sipservlets/> 
> 
>  
> 
> 
> Notice:  This email message, together with any attachments, may contain 
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated 
> entities,  that may be confidential,  proprietary,  copyrighted  and/or 
> legally privileged, and is intended solely for the use of the individual or 
> entity named in this message. If you are not the intended recipient, and have 
> received this message in error, please immediately return this by email and 
> then delete it.
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to