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
