Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
Hello , Yes, it seems I have not mentioned the full messages flow here. Here I explain, On receiving REFER, AS imediately sends NOTIFY(202 Accepted). Then AS can sends from following (RFC 3515, 2.4.5 The Body of the NOTIFY) depending on Call Flow In case of some Error follwoing: - SIP/2.0 503 Service Unavailable - SIP/2.0 603 Declined In case Call is tried to C (sending INVITE to C) - SIP/2.0 100 Trying and when the call is answered: - SIP/2.0 200 OK After the NOTIFY(200 OK), AS sends the BYE to A. In case there is race and A also sends BYE on receving,NOTIFY(200 OK) it's discarded at lower level and AS is not informed. But still I am not understanding making Media Inactive for A. For B we can play some music (by MRF) when C is ringing. -- Thanks Regards Parveen Verma On Wed, Feb 26, 2014 at 10:33 PM, Brett Tate br...@broadsoft.com wrote: Hi Paul, Yes; I likely misinterpreted the meaning of NOTIFY (200 OK) within the question. I also agree that some devices behave as you and Parveen mentioned. I'm not aware of the behavior explicitly documented within an RFC. RFC 5359 does document it that way for attended transfer; however it doesn't document a transfer failure recovery. Thanks, Brett ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
Hi, RFC 6665 and RFC 3515 indicate that a NOTIFY must immediately be sent. RFC 6665 also introduced Timer N which can impacts things if the NOTIFY is delayed until transfer-to device answers. RFC 6665 section 4.2.1.2: Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY request immediately to communicate the current resource state to the subscriber. RFC 3515 section 2.4.2: If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4. RFC 6665 section 4.1.2.4: The subscriber can expect to receive a NOTIFY request from each node which has processed a successful subscription or subscription refresh. To ensure that subscribers do not wait indefinitely for a subscription to be established, a subscriber starts a Timer N, set to 64*T1, when it sends a SUBSCRIBE request. If this Timer N expires prior to the receipt of a NOTIFY request, the subscriber considers the subscription failed, and cleans up any state associated with the subscription attempt. -Original Message- From: Parveen Verma [mailto:parveen.s...@gmail.com] Sent: Wednesday, February 26, 2014 2:41 AM To: sip-implementors Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer Hello, The UAC after sending the REFER does not disconnect the call (sends BYE) until it receives the NOTIFY (200 OK). The other way can also be that AS sends BYE to A's UAC just after sending NOTIFY (200 OK). In our AS does not sends NOTIFY (200 OK) until it receives the answer from C so that there is a option left to A to unhold the call with B. But still I am not finding any reference of any Standard which says so. So I am looking for some reference for this behaviour or what kind of behaviour other AS does in Blind Call Transfer case. -- Thanks Regards Parveen Verma ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
Hi Paul, Yes; I likely misinterpreted the meaning of NOTIFY (200 OK) within the question. I also agree that some devices behave as you and Parveen mentioned. I'm not aware of the behavior explicitly documented within an RFC. RFC 5359 does document it that way for attended transfer; however it doesn't document a transfer failure recovery. Thanks, Brett -Original Message- From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] Sent: Wednesday, February 26, 2014 11:05 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer Brett, The facts of Parveen's case arent entirely clear here. You both might be correct. I *think* Parveen is saying that the UAC is waiting for a NOTIFY containing a sipfrag with the 200 OK for the referred invite. Presumably it could have received an earlier notify reporting a provisional response. AFAIK it is fine for the UAC to keep its own invite dialog active until it gets a notification that the referred INVITE has completed successfully, or until the subscription terminates. As Parveen notes, this allows the UAC to recover the dialog if the refer is unsuccessful. Thanks, Paul On 2/26/14 6:48 AM, Brett Tate wrote: Hi, RFC 6665 and RFC 3515 indicate that a NOTIFY must immediately be sent. RFC 6665 also introduced Timer N which can impacts things if the NOTIFY is delayed until transfer-to device answers. RFC 6665 section 4.2.1.2: Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY request immediately to communicate the current resource state to the subscriber. RFC 3515 section 2.4.2: If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4. RFC 6665 section 4.1.2.4: The subscriber can expect to receive a NOTIFY request from each node which has processed a successful subscription or subscription refresh. To ensure that subscribers do not wait indefinitely for a subscription to be established, a subscriber starts a Timer N, set to 64*T1, when it sends a SUBSCRIBE request. If this Timer N expires prior to the receipt of a NOTIFY request, the subscriber considers the subscription failed, and cleans up any state associated with the subscription attempt. -Original Message- From: Parveen Verma [mailto:parveen.s...@gmail.com] Sent: Wednesday, February 26, 2014 2:41 AM To: sip-implementors Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer Hello, The UAC after sending the REFER does not disconnect the call (sends BYE) until it receives the NOTIFY (200 OK). The other way can also be that AS sends BYE to A's UAC just after sending NOTIFY (200 OK). In our AS does not sends NOTIFY (200 OK) until it receives the answer from C so that there is a option left to A to unhold the call with B. But still I am not finding any reference of any Standard which says so. So I am looking for some reference for this behaviour or what kind of behaviour other AS does in Blind Call Transfer case. -- Thanks Regards Parveen Verma ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
On 2/26/14 12:03 PM, Brett Tate wrote: Hi Paul, Yes; I likely misinterpreted the meaning of NOTIFY (200 OK) within the question. I also agree that some devices behave as you and Parveen mentioned. I'm not aware of the behavior explicitly documented within an RFC. RFC 5359 does document it that way for attended transfer; however it doesn't document a transfer failure recovery. For blind transfer it does present some UI challenges. The transferring party has presumably hung up the phone. So do you alert to get them back if the transfer fails? It is probably easier to handle with a soft phone, that has more UI options. But this is clearly more user friendly that silently letting the transfer fail. Thanks, Paul Thanks, Brett -Original Message- From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] Sent: Wednesday, February 26, 2014 11:05 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer Brett, The facts of Parveen's case arent entirely clear here. You both might be correct. I *think* Parveen is saying that the UAC is waiting for a NOTIFY containing a sipfrag with the 200 OK for the referred invite. Presumably it could have received an earlier notify reporting a provisional response. AFAIK it is fine for the UAC to keep its own invite dialog active until it gets a notification that the referred INVITE has completed successfully, or until the subscription terminates. As Parveen notes, this allows the UAC to recover the dialog if the refer is unsuccessful. Thanks, Paul On 2/26/14 6:48 AM, Brett Tate wrote: Hi, RFC 6665 and RFC 3515 indicate that a NOTIFY must immediately be sent. RFC 6665 also introduced Timer N which can impacts things if the NOTIFY is delayed until transfer-to device answers. RFC 6665 section 4.2.1.2: Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY request immediately to communicate the current resource state to the subscriber. RFC 3515 section 2.4.2: If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4. RFC 6665 section 4.1.2.4: The subscriber can expect to receive a NOTIFY request from each node which has processed a successful subscription or subscription refresh. To ensure that subscribers do not wait indefinitely for a subscription to be established, a subscriber starts a Timer N, set to 64*T1, when it sends a SUBSCRIBE request. If this Timer N expires prior to the receipt of a NOTIFY request, the subscriber considers the subscription failed, and cleans up any state associated with the subscription attempt. -Original Message- From: Parveen Verma [mailto:parveen.s...@gmail.com] Sent: Wednesday, February 26, 2014 2:41 AM To: sip-implementors Subject: Re: [Sip-implementors] SIP REFER to a Blind Call Transfer Hello, The UAC after sending the REFER does not disconnect the call (sends BYE) until it receives the NOTIFY (200 OK). The other way can also be that AS sends BYE to A's UAC just after sending NOTIFY (200 OK). In our AS does not sends NOTIFY (200 OK) until it receives the answer from C so that there is a option left to A to unhold the call with B. But still I am not finding any reference of any Standard which says so. So I am looking for some reference for this behaviour or what kind of behaviour other AS does in Blind Call Transfer case. -- Thanks Regards Parveen Verma ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Re: [Sip-implementors] SIP REFER to a Blind Call Transfer
HI Parveen I guess reason of putting call on hold before initiating another call from same UA is that UA have single instance of media resources which can be used for one active call . But another thing is for blind transfer scenario, after UA triggering transfer and sending Refer need not to stay in call so call can be disconnected(thats why called blind transfer) rather of putting on hold . In case of consultative transfer ,Add call ,conference scenarios we normally need to put call on hold . Thanks regards Ankur Bansal On Mon, Feb 24, 2014 at 8:04 PM, Parveen Verma parveen.s...@gmail.comwrote: Hi All, I have a question regarding the below scenario. Scenario: A calls B, call is established and then A initiates Blind Call Transfer to C. In this case before sending REFER, the UAC of A puts the media as InActive for A to B call and this way puts the A to B call on hold. In Case, Call is not put on Hold by A earlier then our AS puts the Call on Hold after receiving the REFER and then sends NOTIFY to A. Now my doubt is what is the need for putting the Call between A B on Hold. I checked the RFC 3515 http://tools.ietf.org/html/rfc3515, but do not found any such specification. Does any one has an idea why this is done by UAC/AS or any pointer leading to this behaviour. Thanks Regards Parveen Verma ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
