Thanks Paul and Rayees for your helpful comment. I have a question regarding section 3.1.2 Receiving CANCEL in Mora state. After F6, can both Alice and Bob send BYE? i.e who should decide whether to terminate the established dialog in case that UAC tried to CANCEL the dialog before? UAC? UAS? Both UAC and UAS? Even though UAS can send BYE to UAC theoretically, I think it is reasonable for UAC to decide what to do next. I think UAS doesn't need to send BYE because CANCEL doesn't impact on the established dialog.
Regards, Sumin. On 5/15/07, Rayees Khan <[EMAIL PROTECTED]> wrote: > > > Inline. > > regards > Rayees > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sumin Seo > Sent: Monday, May 14, 2007 10:43 PM > To: [email protected] > Subject: [Sip-implementors] Inquiry about B2BUA signaling flow > > Hi All, > > I have questions regarding signaling flow. > > 1. > UA1 <----------------------> B2BUA <-----------------------------> UA2 > INVITE INVITE > ------------------------------------> > ---------------------------------------> > 100 Trying 100 Trying > <--------------------------------- > <----------------------------------------- > Let's say UA1 wants to cancel the call at this point. > Can B2BUA process two call legs separtely? > > Yes, as long as each leg of the call binds to SIP rules these can be > processsed seperately. In fact this is what most of the B2BUAs do. > > i.e Can B2BUA initiate 487 Request Terminated to UA1 after receiving > 200 OK response to CANCEL from UA1? If possible, canceling the call leg > between B2BUA and UA2 will be process as belows. > B2BUA sends CANCEL to UA2 and UA2 returns 487 Request Terminated to > B2BUA. > B2BUA doesn't forward the 487 Request Terminated to UA1. B2BUA sends > ACK to 487 Request Terminated to UA2. > > This would be an acceptable behaviour. > > 2. > UA1 B2BUA UA2 > > INVITE INVITE > ------------------------------------> > ---------------------------------------> > 100 Trying 100 Trying > <--------------------------------- > <----------------------------------------- > CANCEL > ------------------------------------> > 200 OK to CANCEL > <------------------------------------ > 200 OK to INVITE > > <------------------ > CANCEL > ------------------> 2.1. Should > B2BUA forward 200 OK response to INVITE to UA1 if B2BUA receives the 200 > OK after sending CANCEL to UA2? > > My opinion is that it does not make sense to foreward this 200 OK to UA1 > as it is most likely to be ignored in any case. > > > 2.2 Can B2BUA do the followings? > B2bUA sends 200 OK response to CANCEL to UA1 followed by 487 > Request Terminated. And B2bUA sends ACK to 200 OK to UA2 and then send > BYE to UA2. > > My take is that this would be fine. > > > 3. Can UA1 send BYE before sending final response to INVITE? if that is > possible, what is the expected behavior of B2BUA? > > UA1 can send a BYE if it has received a reliable response. For that leg > of the call B2BUA is supposed to response to BYE and take decision on > what to do with other leg of the call. > > 4. B2BUA had sent CANCEL to UA2. After that, It received BYE from UA1. > But it hasn't received a final response to INVITE yet. Can B2BUA forward > BYE to UA2? Is it necessary for B2BUA to wait for 200 OK response to > CANCEL from > UA2 when it sends BYE to UA2? > > I do not think it would be appropriate to foreward BYE to other leg. I > guess the main point here is that B2BUA has to treat each leg as a > separate dialog and events on one leg do force some action on other leg, > but that does not necessarily mean simple forewarding of message. It has > to make a judgement call as to what is appropriate. > > 5. If B2BUA receives BYE from UA1 shortly after B2BUA sent BYE to UA1, > which response should be sent by B2BUA? 200 OK or 491 Request Pending? > > This situation would be same between two UAs. So the rules applying > there would apply here as well. I guess 491 would be acceptable in this > case. > > > I would appreciate your support. > > Regards, > Sumin > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > > > ---------------------------------------------------------------------------------- > IMPORTANT The information contained in this e-mail any > attachments is intended only for the named recipient and may be > privileged or confidential. > > If you are not the intended recipient, please notify us immediately > on +44 (0)1908 425000 and do not disclose, copy, distribute > or take any action based on the contents of this e-mail. > > You should understand and accept that, when communicating with us > by e-mail, it is not a totally secure communication medium. > > We accept no liability for any direct, indirect or consequential loss > arising from any action taken in reliance on the information contained > in this e-mail and give no warranty or representation as to its accuracy > or reliability. > > DIGITALK has the facility to monitor and read both incoming > and outgoing communications by e-mail. In line with industry efforts > to reduce the proliferation of Un-Solicited SPAM messages, > DIGITALK uses various methods including Reverse-DNS > lookups and ban-lists to prevent malicious content reaching our users. > > This message and any attachments has been scanned for known > viruses. However, we would advise you to ensure the content is > indeed virus free. We do not, to the extent permitted by law, accept > any liability (whether in contract, negligence or otherwise) for any virus > infection and/or external compromise of security and/or breach of > confidentiality in relation to transmissions sent by e-mail. > > VAT No: GB 876 3287 81. Reg No: 3080801 > Place of Registration: England > Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes > > ----------------------------------------------------------------------------------" > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
