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
