Pandurangan R S wrote:
>> In such a case UAC and NOTIFIER would destroy then SUBSCRIBE
>> dialog quietly.
>
> NOTIFIER will destroy the dialog as per RFC3265.
> But how/why did the UAC destroy subscribe dialog? I think it has to
> wait for the NOTIFY.
>
>> Now my questions are -
>> 1. Does the proxy server have to start a timer for receipt of NOTIFY?
>> 2. What should be the value of such a timer, if any?
>
> NOTIFY can come after quite a long time (authorization may take a long
> time, if interacting with user, a primary reason that
> subscription-state is *finally* conveyed in a NOTIFY message, a
> separate transaction)
This is wrong.
INVITE can take a long time, which is why the invite transaction has its
own state machine and the ACK.
SUBSCRIBE is a normal sip transaction, and times out like one, after
(IIRC) 32 seconds.
Re the original question:
Did the proxy Record-Route? If not then it won't see the NOTIFY anyway.
The recent clarifications to SUB/NOT (in progress) make it clear that
the dialog/dialog-usage for SUBSCRIBE is established by the NOTIFY, not
by the SUBSCRIBE. So if the proxy is dialog stateful, then it can
capture some *tentative* state based on the SUBSCRIBE, and then watch
for NOTIFYs. (The SUBSCRIBE may be forked.) When/if it sees them it can
establish actual dialog state. If the SUBSCRIBE transaction times out
without there having been any NOTIFYs, then the proxy can forget the
whole thing.
Thanks,
Paul
>> 3. Won't this timer be, if there's any, similar to session-expires timer?
>
> Anyway, subscribe dialog lifetime is bound (even at proxy, if dialog
> stateful) based on expires header 2xx response for subscribe. So I
> don't think any other timer is required.
>
> On Mon, Dec 14, 2009 at 5:43 PM, Dushyant Dhalia
> <dushyant.dha...@rancoretech.com> wrote:
>> The scenario is as follows -
>>
>> 1. UAC sends SUBSCRIBE.
>> 2. Proxy forwards SUBSCRIBE to the NOTIFIER.
>> 3. NOTIFIER sends 200 (OK) which is received by the UAC.
>> 4. NOTIFIER sends NOTIFY which is lost, retransmissions are also lost.
>>
>> As per RFCs 3265 and 5057 subscribe usage should be destroyed in such a
>> scenario. See sec. 4.2 of RFC 5057 (NOTIFY or refresh-SUBSCRIBE request
>> timeout). In such a case UAC and NOTIFIER would destroy then SUBSCRIBE
>> dialog quietly.
>>
>> Now my questions are -
>> 1. Does the proxy server have to start a timer for receipt of NOTIFY?
>> 2. What should be the value of such a timer, if any?
>> 3. Won't this timer be, if there's any, similar to session-expires timer?
>>
>> Regards,
>> Dushyant P S Dhalia,
>> Rancore Technologies, INDIA
>>
>> --
>> "When work is a pleasure, life is a joy! When work is duty, life is
>> slavery."
>>
>> _______________________________________________
>> 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
