[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] REFER's implicit subscription times	out.Resubscribe how?
From:       Paul Kyzivat <pkyzivat () cisco ! com>
Date:       2006-07-26 21:19:02
Message-ID: 44C7DC46.10402 () cisco ! com
[Download RAW message or body]

In sip, all subscriptions have an expiration time. Normally that time is 
negotiated between the UAC and UAS with headers in the SUBSCRIBE and the 
response to it.

The implicit subscription for REFER is a bit of a hack. As a result, 
there is no provision for negotiating the expiration time. The UAC has 
to depend on the UAS telling it the expiration time. It will learn this 
when it receives the first NOTIFY. The first NOTIFY is supposed to be 
send right away when the subscription is established, so there should be 
no significant delay. (BUT, between the time when the REFER is sent and 
the time when the first NOTIFY is received, the UAC has no idea what the 
expiration time will be.)

The expiration time for the subscribe need have no relationship to the 
lifetime of the referred INVITE. The UAS has to pick a value, typically 
without knowing how long it will need to be. Also typically the UAS will 
send a final NOTIFY terminating the subscription when the referred 
request completes. But it doesn't have to do so. It could leave it 
indefinitely, or at least until the referred call completes. (Though 
once the REFER has been satisfied it isn't clear what further NOTIFYs 
there might be.) Its also possible that the expiration time might be 
short, and run out while the referred call is still ringing. That is 
probably the case when the UAC might want to refresh it.

A *nice* UAS will probably set the expiration time longer than it would 
ever allow the REFER to remain incompleted, so the UAC will *probably* 
never need to do a refresh. But its up to you whether you want to trust 
that all the UASs you deal with are "nice".

	Paul

Kedar Karmarkar wrote:
> What does the subscription timeout consist of, is it mostly the terminating
> ring timeout and some processing delay?
> 
> In the telecom world, the transferor is in effect, indefinately subscribed
> to the state of the transferee, unless the transferor gets tired and hangs
> up, or the transferee does'nt pick the call. In that sense, so long as the
> transferee ring timeout has not expired, the "subscription" does not expire,
> hence on the SIP side, the subscription interval is probably of the order
> of the ring timeout plus processing time, and in that case, requesting an
> extention is probably not going to be of much use, as an expired
> subscription logically means that the transferee did not pick the call on
> time. Is this argument accurate?
> 
> Kedar
> 
> On 7/26/06, Frank Shearar <frank.shearar@angband.za.org> wrote:
>> My first recommendation below is bogus. That is, RFC 3265 says in section
>> 3.1.1 that
>>
>>   200-class responses to SUBSCRIBE requests also MUST contain an
>>   "Expires" header.  The period of time in the response MAY be shorter
>>   but MUST NOT be longer than specified in the request.  The period of
>>   time in the response is the one which defines the duration of the
>>   subscription.
>>
>> so the transferee ALWAYS uses expiry with REFER. Thus, the transferor had
>> better resubscribe timeously.
>>
>> frank
>>
>> ----- Original Message -----
>> From: "Frank Shearar" <frank.shearar@angband.za.org>
>> To: "SIP Implementors" <sip-implementors@cs.columbia.edu>
>> Sent: Wednesday, July 26, 2006 10:18 AM
>> Subject: Re: [Sip-implementors] REFER's implicit subscription times
>> out.Resubscribe how?
>>
>>
>>> As Somesh says, a REFERred UA typically ends the subscription with
>>> reason=noresource.
>>>
>>> I think the lesson here is that, as RFC 3515 says, the subscription is
>>> implicit, and doesn't have a fixed expiry date. It expires when the far
>> side
>>> succeeds, fails or declines the transfer.
>>>
>>> Thus, I'd say that ideally (using call transfer terminology)
>>> (a) the transferee shouldn't use expiry at all with REFER, and
>>> (b) if she does, the transferor had better make sure she resubscribes to
>> the
>>> REFER timeously.
>>>
>>> Thanks!
>>>
>>> frank
>>>
>>> ----- Original Message -----
>>> From: "Paul Kyzivat" <pkyzivat@cisco.com>
>>> To: "Frank Shearar" <frank.shearar@angband.za.org>
>>> Cc: "SIP Implementors" <sip-implementors@cs.columbia.edu>
>>> Sent: Tuesday, July 25, 2006 6:51 PM
>>> Subject: Re: [Sip-implementors] REFER's implicit subscription times out.
>>> Resubscribe how?
>>>
>>>
>>>> Yes, in this case you are out of luck. You can't get back to that
>>>> subscription.
>>>>
>>>> Paul
>>>>
>>>> Frank Shearar wrote:
>>>>> Following on from my previous question, say I send A a REFER. A
>> tells
>> me
>>> the
>>>>> subscription's duration. I'm too lazy to respond quick enough with a
>>>>> resubscription, and A sends me a NOTIFY with "Subscription-State:
>>>>> terminated;reason=timeout".
>>>>>
>>>>> How can I resubscribe?
>>>>>
>>>>> Remember that RFC 3515 says "follow the procedure in RFC 3265". RFC
>> 3265
>>>>> says in section 3.2.4 "Subscriber NOTIFY Behavior"
>>>>>
>>>>>    timeout: The subscription has been terminated because it was not
>>>>>       refreshed before it expired.  Clients MAY re-subscribe
>>>>>       immediately.  The "retry-after" parameter has no semantics for
>>>>>       "timeout".
>>>>>
>>>>> Of course, if you try that with a REFER you end up creating a
>> SUBSCRIBE
>>> with
>>>>> "Event: refer" that does not match any existing subscription, and A
>>> rightly
>>>>> rejects the SUBSCRIBE with a 403 Forbidden (as per RFC 3515 section
>>> 2.4.4).
>>>>> Is it simply the case that you CAN'T resubscribe this implicit
>> REFER?
>> If
>>> I
>>>>> sent another REFER, it's not quite the same as a normal SUBSCRIBE.
>> (I'm
>>> not
>>>>> asking for state change notifications, I'm asking A to do
>> something.)
>>>>> frank
>>>>>
>>>>> _______________________________________________
>>>>> Sip-implementors mailing list
>>>>> Sip-implementors@cs.columbia.edu
>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 

[prev in list] [next in list] [prev in thread] [next in thread]