Hi Sumin, You are right since UAS dialog is not changed by receiving CANCEL as dialog is established, UAC has to send BYE in this case to terminate the dialog. regards Rayees
________________________________ From: Sumin Seo [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 9:48 AM To: Rayees Khan Cc: [email protected] Subject: Re: [Sip-implementors] Inquiry about B2BUA signaling flow 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 ------------------------------------------------------------------------ ----------" ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
