Paul Kyzivat wrote:
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.
[Dushyant]
Yes, the proxy inserted Record-Route.
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.
[Dushyant]
SUBSCRIBE transaction has not timed out. UAC has received 200 OK for
SUBSCRIBE but it has not (and won't) received NOTIFY. So, as per the
above clarification (and RFC 3265) PROXY has entered the *neutral*
state but the actual dialog state has not been established.
As suggested by Sumit and Pandurangan, if i maintain SUBSCRIBE dialog
for the timer sent in Expires header of 200 OK (which at times might be
as large as one week in IMS) then i would be wasting my resources at
PROXY server unnecessarily which is my concern.
My suggested solution is - PROXY should wait for 32 seconds
(retransmission of NOTIFY) + 2 seconds (delay in network) and after
that it should clear its resources.
Also, what should be the behavior at the UAC (subscriber)?
Thanks,
Dushyant
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
--
"When work is a pleasure, life is a joy! When work is duty, life is slavery."
|
