Hi, First, the resource for media and one thing, and the resource for transanction is another thing. Once SIP-Phone, for example, sends BYE, SIP-Phone should release the resource for the media and be ready for the next call immediately. It is non-sense that the next call have to wait for 32 seconds just waiting for 200 OK for BYE in the last call. But, at the same time, you should keep transaction state as described in RFC 3261.
Regarding the transaction state, for unreliable transport, UAC must maintain the state and keep sending BYE until it receive the response to make sure that the request is successfully received at the peer. As pointed out by Paul, UA should not rely on the assumption that UAS can detect the call termination at the peer by using any ethod other than SIP protocol. When UA use a reliable transport like TCP, UA may have other implementation choice, I think. UAC will not retransmit BYE request. Note that transaction layer is a logical layer in SIP protocol architecture. Assumig that any respose to BYE including 200 OK or timeout will not take effect on UA, then UA virtually forget any transaction state once BYE packet is acknowledged at the transport layer. I think the behaviour is logically the same with or without transaction state. Note that, even in this circumstance, UA should keep transport connection for the response to be sent over. Regards, Takuya > [Moved to sip-implementors] > > William, > > You seem to assume that all calls are about voice, or at least RTP, and > that in the absence of RTP the call is failed. Maybe that is the case > for your endpoint, depending on what you are building, but it isn't true > in general. > > Even with RTP, the absence of traffic isn't necessarily a problem. > > I am inclined not to give up on a call so easily. If you think something > is wrong, why not send a reINVITE to test the signaling path first? > > At the very least, have some consideration that other endpoints may not > be as picky as you are. > > In any case, the protocol says that if you don't get a 200 OK, even for > a BYE, you should keep retransmitting until all the timers expire and yo > finally give up. If you choose not to do this then you will have built a > non-conforming device. (Maybe this will have to be added to the torture > tests.) > > Paul > > William StanisLaus wrote: > > I agree with you Davidson.. I'm talking about proper implementation all > > these time, which can detect RTP dropping :) > > > > -William. > > > > > >>-----Original Message----- > >>From: Davidson, Michael D [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, May 27, 2004 9:00 PM > >>To: [EMAIL PROTECTED]; Fred Hasle; Juha Heinanen > >>Cc: [EMAIL PROTECTED]; Shriram Natarajan; Srinivasa Rao > >>Subject: RE: [Sip] BYE and 200 OK > >> > >> > >>If this call interworked to the PSTN then you run the risk of > >>this call staying up until the far end hangs up. I know that > >>there are several gateway vendors that never tear down the > >>call based on the RTP stream stopping. They leave the call > >>up until they either receive the BYE from the SIP side or a > >>disconnect from the PSTN side. In this situation, if the far > >>end does not hang up you will continue to be billed for the > >>call for a potentially very long time. If implemented > >>properly, there are other devices such as border controllers > >>that will detect the RTP dropping, but this is not something > >>that you can necessarily count on. > >> > >> > >> -----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] On Behalf Of William StanisLaus > >>Sent: Thursday, May 27, 2004 9:47 AM > >>To: 'Fred Hasle'; 'Juha Heinanen' > >>Cc: [EMAIL PROTECTED]; 'Shriram Natarajan'; 'Srinivasa Rao' > >>Subject: RE: [Sip] BYE and 200 OK > >> > >> << File: ATT585321.txt >> I'm claiming that i need not > >>implement retransmit timer for BYE nor hold the resources > >>after i dispose BYE. > >>I close all my resources immediately after i send BYE. So no > >>hanging network resources. > >>including the CALL LEG and transcation for this CALL. > >> > >>-William. > >> > >> > >>>-----Original Message----- > >>>From: Fred Hasle [mailto:[EMAIL PROTECTED] > >>>Sent: Thursday, May 27, 2004 8:10 PM > >>>To: [EMAIL PROTECTED]; Juha Heinanen > >>>Cc: [EMAIL PROTECTED]; Shriram Natarajan; Srinivasa Rao > >>>Subject: RE: [Sip] BYE and 200 OK > >>> > >>> > >>>The receipt of a 200 (OK) will not provide you any "spice" as > >>>you said, > >>>but the receipt of a 200 (OK) is the only guarantee that > >> > >>you have, as > >> > >>>the initiator of the BYE, to know that all the network > >>>resources between > >>>you and the UAS have been released. > >>>If you discard the timeout, there could be dangling network > >> > >>resources, > >> > >>>because you as the UAC did not retransmit the BYE. > >>>In my view, the 200 (OK) is mostly used to cancel your > >> > >>retransmission > >> > >>>procedure. > >>>Fred. > >>> > >>>-----Original Message----- > >>>From: William StanisLaus [mailto:[EMAIL PROTECTED] > >>>Sent: Thursday, May 27, 2004 9:49 AM > >>>To: 'Juha Heinanen' > >>>Cc: [EMAIL PROTECTED]; 'Shriram Natarajan'; 'Srinivasa Rao' > >>>Subject: RE: [Sip] BYE and 200 OK > >>> > >>>Ofcourse you are right , USER A cannot differentiate BYE > >>>getting LOST or > >>>USER B is PANIC, So i should not wait for TIMEOUT and close the Call > >>>Leg.. > >>>Once i dispose BYE, immediately i should release my > >> > >>resource and close > >> > >>>the > >>>CALL LEG. > >>> > >>>My question is WHY should i wait for 200 OK or TIMEOUT for BYE !!! > >>>Does 200 OK is going to bring any spice to my CALL LEG, AM > >> > >>i going to > >> > >>>continue my call after BYE based on any response (not only > >> > >>200 OK)!!! > >> > >>>Otherwise am i implemented an intelligent system (SIP STACK) > >>>to remember > >>>200 > >>>OK information for this USER B, so that if i call again, > >> > >>i'll use the > >> > >>>information i got in my last call. NO > >>> > >>>so I need not to wait for 200 OK or TIMEOUT after i dispose BYE. > >>> > >>>-William. > >>> > >>> > >>>>-----Original Message----- > >>>>From: Juha Heinanen [mailto:[EMAIL PROTECTED] > >>>>Sent: Thursday, May 27, 2004 7:07 PM > >>>>To: [EMAIL PROTECTED] > >>>>Cc: 'Srinivasa Rao'; 'Shriram Natarajan'; [EMAIL PROTECTED] > >>>>Subject: RE: [Sip] BYE and 200 OK > >>>> > >>>> > >>>>William StanisLaus writes: > >>>> > >>>> > But this is silly.. since my USER B is dead.. entered > >>>>PANIC MODE !!! and > >>>> > cannot reply anything... Hence USER A cannot keep > >>> > >>sending BYE... > >> > >>>>how can A tell the difference between bye getting lost and B > >>>>being dead? > >>>> > >>>>-- juha > >>>> > >>> > >>> > >>>_______________________________________________ > >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use [EMAIL PROTECTED] for questions on current sip > >>>Use [EMAIL PROTECTED] for new developments on the application of sip > >>> > >> > >> > >>------------------------------------------------------------------------ > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use [EMAIL PROTECTED] for questions on current sip > >>Use [EMAIL PROTECTED] for new developments on the application of sip > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
