Hi, Thanks for the response. I need to clear up what it is that I mean. I don't mean that the client transaction has actually failed (the re-INVITE has timed out), it has just not yet received a response when the UAC hangs up the call (apologies for the telephony speak, it is my background talking). The client transaction is alive and well and busy retransmitting the re-INVITES. It is in this situation that I am unsure how to act.
Cheers Steve -----Original Message----- From: Peili Xu [mailto:[EMAIL PROTECTED] Sent: 28 September 2005 15:50 To: Stephen Paterson; [email protected] Subject: Re: [Sip-implementors] Handling of session clears during re-INVITEtransaction If both reINVITE transaction and BYE transaction fail, you can just release locally, clear the resources aquired during the session. ----- Original Message ----- From: "Stephen Paterson" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, September 28, 2005 10:38 PM Subject: [Sip-implementors] Handling of session clears during re-INVITEtransaction > Hi, > > After a successful session set up, a UAC initiates a re-INVITE for any > reason but has not yet received a response before it decides to clear the > session. This will also apply to any mid-session request but my current > concern is with re-INVITEs. > I've been unable to find any guidance on the RFC/draft pages and was hoping > for some help. > I've had a discussion with some of my colleagues and the following call flow > shows our thoughts on what should happen: > > UAC UAS > | | > | INVITE/200/ACK | > | <-------------------------------> | > | | > | Both way RTP established | > | | > | re-INVITE (CSeq 2) | > | --------------------------------> | > | re-INVITE (CSeq 2) | > | --------------------------------> | > | BYE (CSeq 3) | > | --------------------------------> | > | 487 (CSeq 2) | > | <-------------------------------- | > | 200 (CSeq 3) | > | <-------------------------------- | > | ACK (CSeq 2) | > | --------------------------------> | > > If the UAS was not responding to the re-INVITE due to network problems it > would also not be responding to the BYE which would re-transmit and timeout > as usual. > > Any thoughts on how this situation should be handled much appreciated. > Ideally I am looking for an RFC or draft which will define the correct > behaviour. > > Cheers > > Steve > > Steve Paterson > Aculab > Tel: +44 (0) 1908 273866 > Fax: +44 (0) 1908 273801 > Email: mailto:[EMAIL PROTECTED] > Website: http://www.aculab.com > > _______________________________________________ > 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
