Anders Kristensen wrote:
>
>
> Paul Kyzivat wrote:
>> I think the part that is not clearly specified is when the referee may
>> terminate the subscription. It must send at least one NOTIFY, but I
>> think it principle it could set the subscription state to terminated
>> in the very first NOTIFY if it wanted, even though the referred
>> request is still incomplete.
>
> From 3515:
>
> Note that agents accepting REFER and not wishing to hold
> subscription state can terminate the subscription with this initial
> NOTIFY.
>
>>
>> Conversely, AFAIK there is no requirement that the subscription be
>> terminated when the referred operation completes. If the REFER was for
>> an INVITE, normally the subscription is terminated on the final
>> response, but it could in principle keep sending notifications while
>> the call is active.
>
> That's what I thought but actually the RFC does state that the resource
> subscribed to is the triggered transaction and as such it must terminate
> when the transaction terminates. 3515 again:
>
> The final NOTIFY sent in response to a REFER MUST indicate
> the subscription has been "terminated" with a reason of "noresource".
> (The resource being subscribed to is the state of the referenced
> request).
>
> and later:
>
> The lifetime of the state being subscribed to is
> determined by the progress of the referenced request.
>
> I thought there was even more explicit text but can't find it right now.
Well, the above doesn't actually *say" its talking about the
*transaction". It talks about the progress of the request. I think it
still might be possible to consider an INVITE to still be making
progress as long as the dialog it creates still exists. (Though that
might be a stretch.)
Paul
> Thanks,
> Anders
>
>>
>> For the original question, take a look at RFC 4488, defining the
>> norefersub option. If the referror doesn't want the subscription then
>> this is an option. But it isn't an option for the referee on its own.
>>
>> Paul
>>
>> Scott Lawrence wrote:
>>> On Thu, 2008-02-21 at 16:33 -0800, Dushyant Godse wrote:
>>>> Hello
>>>> I was referencing the RFC 3515 regarding messaging for transfers based
>>>> on SIP REFER.
>>>> Is the UA processing the REFER required to send NOTIFY subscription
>>>> event messages to the sender agent notifying the progress of the
>>>> transfer like 100 trying, 180 ringing, 200 OK. Is this a MUST?
>>>>
>>>> I am pasting below a snippet of the RFC which says it must. I would
>>>> like
>>>> to confirm this within the forum
>>>> 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.
>>> What is the ambiguity? MUST means what it says.
>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
