I also am a bit confused about the semantics of "Subscription-State" header
in NOTIFY. It seems to me, it has some different meaning depending on, when
NOTIFY is sent (but in most practical sceanarios, probably those two
meanings will overlap)
For example consider the following scenario:
| |
|-------SUBSCRIBE1-------->|
| |
|<---200(SUBSCRIBE1)-------|
| |
|<---NOTIFY1(active)-------|
| |
|-----200(NOTIFY1)-------->|
| |
| ..... |
NOTIFY <----|<---NOTIFY2(active)-------|
because of | |
state change |----200(NOTIFY2)--------->|
of the | |
subscribed entity/resource.... |
| |
| |
refresh <----|------SUBSCRIBE2--------->|
before subscription | |
expires |<---200(SUBSCRIBE2)-------|
| |
|<---NOTIFY3(pending)------|
| |
|----200(NOTIFY3)--------->|
| |
| .... |
| |
NOTIFY <----|<---NOTIFY4(x)------------|
because of | |
state change | |
of the | |
subscribed entity/resource |
| |
| |
NOTIFY | |
because <---|<---NOTIFY5(terminated)---|
SUBSCRIBE2 not | |
allowed | |
| |
| |
| |
Let's assume, when NOTIFY4 was sent, SUBSCRIBE2 was not accepted yet by
notifier. What should be "Subscription-Status"? I would expect it to be
"active". But in such a case, how to distinguish between NOTIFY(active) sent
to confirm SUBSCRIBE2 and a NOTIFY(active) sent as a result of state changed
of the subscribed entity? One possible could argue, that the former one
SHOULD have "expires" parameter in the "Subscription-State" header, but
including it is a SHOULD, not a MUST, and as explained in RFC3265, more
usefull for forking scenarios, so might be not used, if forking is not
possible. If we want to rely on it, I would expect it to be a MUST, because
not putting it would break the protocol. So, if it is not present, I don't
see a way to decide on the subscriber side, for what reason this
NOTIFY(active) is sent. Furthermore, NOTIFY4(active) also brings some
confusion about the semantics of "Subscription-State". Sometimes, it shows
the status about a specific SUBSCRIBE (for example NOTIFY1(active) shows
that SUBSCRIBE1 was accepted, and NOTIFY3(pending) shows that SUBSCRIBE2 is
pending), and sometimes the status of the overall subscription relationship
(for example NOTIFY4(active) ) -whose deatils in the RFC3265 are not
defined, it just "exists" or "does not exist"-.
A similar situation is present for NOTIFY5(terminate). But at least, it
seems like looking to "reason" parameter might save us. If it is "rejected"
than it is sent for the last sent/received SUBSCRIBE, and it it is "expired"
it is for the whole subscription.
Now, if one decides to send NOTIFY4(pending) in the above scenario, then
there is no need to rely on existence of "expires" field. But the mixed
semantics of "Subscription-State" still exists because of
NOTIFY5(terminated), it shows SUBSCRIBE acceptance state or subscription
state, depending on "reason" parameter.
So, what should be "Subscription-State" in NOTIFY4?
Tolga
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Vijaya
> Venkatachalam
> Sent: Friday, October 31, 2003 1:06 PM
> To: [EMAIL PROTECTED]
> Subject: [Sip-implementors] SIP Event Notification
>
>
> Hi!
>
> I have a question on RFC 3265.
> When a SUBSCRIBE refresh is sent and a
> NOTIFY pending is received for this refresh,
> does the subscription state at the Subscriber
> change to "pending" from "active" or does
> it remain "active" till the remaining duration,
> after which it transitions to "pending" since
> no other NOTIFY "active" is received?
>
>
> Thanks.
>
> --
> Regards,
> Vijaya Venkatachalam
> System Engineering
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
