Hi Hasebe, plz go thru the following, Section from 3261 "15.1.1 UAC Behavior
A BYE request is constructed as would any other request within a dialog, as described in Section 12. Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated." As i understand from the above paragraph that a) its only the session that gets immediately terminated when a BYE request is sent out by the UAC. b) So if the dialog still exists should not the receiver of a BYE be able to respond it with a 200ok (even though it was waiting for a response to a BYE that it has sent out) ??? regds Mallesh On Wed, 23 Mar 2005 17:48:34 +0900, Miki HASEBE <[EMAIL PROTECTED]> wrote: > Hi Malleswara, > > Comments are inline. > > > Can add other cross-overs like Re-INVITE-Re-INVITE (especially when > > both dont carry any SDP), Re-INVITE-UPDATE > > Thank you for your comments. I would like to consider to add these examples. > Please give me some time to think about this. I want to think this over. > > > Some thoughts: > > In Section 2.1, CANCEL cross over can result in a subsequent BYE from > > the UAC. > > In the situation of the CANCEL crossover, the call would be established > nevertheless the onhook state of SIP Phone, when it comes to be in the > situation of a CANCEL crossover. Considering the ordinary telephone, I think > this situation is a problem. According to RFC3261, UA can send BYE message > after the session has been established. So, I think it is a good idea that > the UAC would send BYE automatically just then it receives 200 OK without > noticing to the user. I would like to add the description about sending BYE > message to my draft, considering SIP Phones. > Thank you for your helpful comment. > > > In Section 2.2, for BYE cross over, I think that either of the UAs > > can still respond > > with a 200ok assuming that the BYE it had sent was lost and then can stop > > waiting for a response to its BYE (cuz it doesnot make any more sense to > > even > > retry the BYE) > > I understood that the issue you pointed out. > I explain clearly by using a following sequence diagram. > > Alice Bob > | | > | BYE BYE | > |--------- ----------| > | \ / | > | X | > | / \ | > |<-------- ----> X | > | | > | 200OK | > |----------------------->| > | | > > I think the dialog has been terminated when the server sends the BYE message, > so a 200 OK message cannot be sent. It would come to be the sequence flow as > the following: > > Alice Bob > | | > | BYE BYE | > |--------- ----------| > | \ / | > | X | > | / \ | > |<-------- ----> X | > | | > | 481 | > |----------------------->| > | | > | BYE | > |------------------> X | > | | > | BYE | > |------------------> X | > | : | > | : | > > I think sending BYEs repeatedly is unavoidable, because the client follows > the rule of non-INVITE client transaction described in RFC3261. > > Thank you, again. > Regards, > Miki Hasebe > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
