Subject: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted]

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Apr 2010 13:06:25 +0200

Hi,

For the 3265bis thing the following is stated:

"Unless there are objections on the list, the draft will go into WGLC with these changes."

I think there are still a few issues we need to solve before we should go to WGLC.

1. As indicated in the meeting (also stated in the report), we need to discuss when REFER implicit subscriptions are created - on REFER 200 OK or on NOTIFY.

2. There is still an open issue in the draft whether timer N applies to proxies. I may have missed it, but I don't see any conclusion on that. 

3. A while ago there was a discussion on what happens in case timer N expires. There was a suggestion that the subscription would be terminated, but I am not sure whether there is a decission on that. Also, I think that is impacted by the etag issue I raised on the list a few days ago ('RFC3265/3265bis and draft-ietf-sipcore-subnot-etags issue regarding notification suppression').

If Adam's agenda allows it, having dedicated phone meetings to discuss these issue could be a way to move things forward, in order to be able to initiate the WGLC.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Tuesday, March 30, 2010 9:38 PM
To: SIPCORE
Subject: [sipcore] Minutes Posted

[as chair]

A draft version of the minutes from the recent IETF meeting in Anaheim
has been posted to the proceedings site:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html

Please review the minutes and submit any corrections to the chairs no
later than April 15th. Thank you.

/a
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Apr 2010 09:36:14 -0400

[as individual]

Christer Holmberg wrote:

> 3. A while ago there was a discussion on what happens in case timer N expires. 
>    There was a suggestion that the subscription would be terminated,
>    but I am not sure whether there is a decission on that. 

Are you asking about *initial* subscriptions, or resubscribes?

For initial subscription requests, there is no subscription to terminate.

For resubscribes, its currently an open issue in section B.3.

Are you just asking to have the open issue resolved?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 05 Apr 2010 10:06:52 -0500

On 4/5/10 8:36 AM, Paul Kyzivat wrote:
> [as individual]
>
> Christer Holmberg wrote:
>
>> 3. A while ago there was a discussion on what happens in case timer N 
>> expires.    There was a suggestion that the subscription would be 
>> terminated,

[as a document author]

We had discussion around this point in Stockholm, and drove it to a 
conclusion on list afterwards. I put it up in Anaheim one more time, 
with a summary of what that conversation concluded. If someone wants to 
raise an objection to the decision to treat Timer N expiration the same 
way we treat SUBSCRIBE transaction timeouts, I'm happy to engage in that 
discussion.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 05 Apr 2010 10:16:02 -0500

> I think there are still a few issues we need to solve before we should go to WGLC.

[as document author]

I think you're misinterpreting that statement. It's not saying that the 
document is ready for WGLC -- the proposed resolution for the various 
issues still needs to go into the document. The point of the note is 
that, barring any concrete objections to the proposed resolutions, I'll 
be updating the document to reflect those resolutions, and will treat 
them as closed. In other words, it's the last time I plan on bringing 
them up for discussion. I consider a yearlong effort of waving these 
issues at the working group to be sufficient time to let anyone's 
concerns be expressed.

> 2. There is still an open issue in the draft whether timer N applies to proxies. I may have missed it, but I don't see any conclusion on that.

Where do you see this in the draft?

In any case, proxies don't inherently care about subscription state. If 
you're doing something in your proxy that is attempting to figure out 
the state of a subscription, you need to take care to figure out what's 
going on. In that case, yeah, Timer N is going to be of interest to you. 
But that's not something we need to specify -- it's actually very 
application-specific.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Apr 2010 21:14:09 +0200

Hi,

>>>terminated, but I am not sure whether there is a decission on that.
>>

Resubscribes.

>>For initial subscription requests, there is no subscription to terminate.

Agree.

>>For resubscribes, its currently an open issue in section B.3.

Yes.

>>Are you just asking to have the open issue resolved?

It seems like I missunderstood the report regarding WGLC (see Adam's e-mail), so I said that in my opinion we should solve the issue before we initiate WGLC.

>way we treat SUBSCRIBE transaction timeouts, I'm happy to engage in that

One alternative would be to fallback whatever state was used before the SUBSCRIBE was sent. However, I don't really have any strong opinions about that as such.

My issue was that, IF there are intermediaries that maintain subscription state, and they don't support subnot, they could terminate the subscription in cases where the NOTIFY is suppressed. Of course, in case we would choose that timer N expiration would cause a fallback there could be some state unsynchs between entities.

So, a related question to that was: since the NOTIFY request is so essential to 3265bis, should we allow it to be suppressed in the first place? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Apr 2010 21:37:20 +0200

Hi,

>Where do you see this in the draft?

It is not indicated in the draft. I meant that it is one of the issues I have.

>But that's not something we need to specify -- it's actually very

The draft says that proxies no not need to support anything in addition to 3261, so from that point of view you are correct.

However, at the same time it talks about proxies adding Record-Route if they are interested in the SUBs and NOTs, so I assumed that means that they are "allowed" to actually maintain subscription dialog state - in the same way as they might maintain invite dialog state.

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Tue, 6 Apr 2010 10:55:43 -0700

> If someone wants to raise an objection to the decision to 
> treat Timer N expiration the same way we treat SUBSCRIBE 
> transaction timeouts, I'm happy to engage in that discussion.

The decision has an interesting interaction concerning overload.  More specifically if SUBSCRIBE received from device that the notifier still thinks is in overload, notifier will send 200 response but not the NOTIFY until later.  Or an overloaded middle box throttling some traffic might reject the NOTIFY with 500/503 Retry-After.

Concerning the overload interactions, is the decision concerning Timer N expiration acceptable since not allowing SUBSCRIBE 200 response to confirm the subscription creation?

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Tue, 6 Apr 2010 15:26:04 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]

Even if a proxy is keeping subscription-state information, I don't see Timer N introducing a problem.  The proxy sees all the SUBSCRIBEs and NOTIFYs and their responses.  Under 3265bis, the NOTIFYs, actually, the the *responses* to the NOTIFYs show all of the subscription state.  In particular, in seciton 4.1.2.4, I see:

   Until Timer N expires, several NOTIFY messages may arrive from
   different destinations (see Section 4.4.1).  Each of these messages
   establish a new dialog and a new subscription.  After the expiration
   of Timer N, the subscriber SHOULD reject any such NOTIFY messages
   that would otherwise establish a new dialog with a "481" response
   code.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 22:02:25 +0200

Hi,

>Even if a proxy is keeping subscription-state information, I don't see Timer N introducing a problem.  The proxy sees all the SUBSCRIBEs and NOTIFYs and their responses.  Under 3265bis, the NOTIFYs, actually, the the *responses* to the NOTIFYs show all of the 
>subscription state.  In particular, in seciton 4.1.2.4, I see:
>

Exactly, and that's why I think draft-ietf-sipcore-subnot-etags could cause issues, because it allows the NOTIFY to be suppressed. Now, if the proxy does not support that draft, and it doesn't receive a NOTIFY (since it has been suppressed) it could terminate the subsciption dialog state.

Please also note that my issue is related to re/de-subscriptions, when all dialogs already exist.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 22:04:58 +0200

Hi,

Overload, that would "delay" the NOTIFY, is in fact one of the scenarios I also had in mind, and got me thinking whether it would not simply be better to maintain the pre-SUB dialog state, instead of terminating the dialog.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Brett Tate [[email-masked]]
Sent: Tuesday, April 06, 2010 8:55 PM
To: Adam Roach; SIPCORE
Subject: Re: [sipcore] rfc3265bis: SIP events redux [was  Minutes Posted]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 17:49:32 -0400

[as individual]

I'm having trouble understanding the issue here.
I presume we are talking about *initial* subscribe here, not resubscribe.

IIUC the case under discussion is:

- Bob sends Alice some message
- Alice responds with 503, retry-after
   because she is overloaded
- Alice then sends Bob a SUBSCRIBE
- Bob replies 200 to that
- Bob delays the NOTIFY for the subscribe due to
   the retry-after timer
- Timer-N expires so Alice considers the subscribe a failure.
- Eventually Bob sends the NOTIFY, but Alice rejects it
   with 481
   OR
   Bob realizes that Timer-N has expired and so does not
   send the NOTIFY.

Is there *any* problem here? This seems to be working about as well as 
anyone might hope. What would you expect to happen?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 17:00:15 -0500

> I presume we are talking about *initial* subscribe here, not resubscribe.

[also as individual]

No, we know how initial subscribe behaves. The issue under discussion 
is: what happens if Timer N expires during a resubscription attempt?

/a

---

From: Brett Tate <[email-masked]>
Date: Tue, 6 Apr 2010 15:03:29 -0700

:) My understanding is that both are being discussed since relevant to both situations.

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, April 06, 2010 6:00 PM
> To: Paul Kyzivat
> Cc: Christer Holmberg; Brett Tate; SIPCORE

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 17:44:47 -0500

[as individual]

Ah, okay.

For initial subscriptions: the problem that Timer N solves is a very 
real one. I think it is reasonable to trade-off the ambiguity around 
subscription establishment for the extremely rare failure in overload 
conditions. IMHO, the failure to timer supervise the period between an 
initial SUBSCRIBE and an initial NOTIFY was the largest flaw in RFC 3265 
when we published it.

It's worth mentioning in the bis draft that there can be circumstances 
-- notably, related to congestion conditions -- that might lead to these 
kinds of failures. I'll add something to this effect in the next draft. 
But I think removing Timer N would be a huge step backwards.

Regarding the behavior of Timer N on a *re*subscribe: I don't strongly 
care one way or another. But it needs to be unambiguous and documented. 
I'm happy to say "Timer N expiration on a resubscribe destroys the 
subscription." I'm also happy to say "Timer N isn't even run for 
resubscriptions." I'm slightly biased towards the first case, since the 
situation clearly means something has gone wrong in the network.

Your overload scenario is an interesting one, and we should certainly 
consider how the system should behave in this case. On first blush, it 
seems to me that if the network is so congested that it can't get the 
NOTIFY through within a 32-second window, everyone might benefit from 
the subscription going away anyway.

/a

On 4/6/10 17:03, Apr 6, Brett Tate wrote:
>>> I presume we are talking about *initial* subscribe here, not
>>>        
>> resubscribe.
>>
>> [also as individual]
>>

---

From: Brett Tate <[email-masked]>
Date: Tue, 6 Apr 2010 15:46:22 -0700

> Is there *any* problem here? This seems to be working about 
> as well as anyone might hope. 

It works okay excluding the non backward compatibility with RFC 3265 (concerning SUBSCRIBE's 2xx response impacts) and continuing to uselessly repeat the Timer N expiration's subscription teardown process until related overload issue resolved.

> What would you expect to happen?

Potentially allow the SUBSCRIBE's 200 response to create the subscription/dialog similar to RFC 3265.  

The draft's Timer N (and lack of related NOTIFY) text is potentially worded in a way which does not require the tear down (and non creation) of subscription.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 19:20:43 -0400

> Potentially allow the SUBSCRIBE's 200 response to create the subscription/dialog similar to RFC 3265.  

Then what would happen in a polling subscribe (Expires:0) if the 200 is 
received and the NOTIFY is not received? How long should you wait before 
giving up? ISTM you still need timer-N to tell you it failed, so you can 
give up waiting.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 18:31:22 -0500

On 4/6/10 15:02, Apr 6, Christer Holmberg wrote:
> Exactly, and that's why I think draft-ietf-sipcore-subnot-etags could cause issues, because it allows the NOTIFY to be suppressed.

You're conflating *initial* NOTIFYs with *refresh* NOTIFYs.

The subnot-etags document explicitly does not allow suppression of 
initial NOTIFY messages. They are critical to establishing a dialog.

The text Dale cites relates exclusively to handling of *initial* 
NOTIFYs. It is unrelated to the kinds of NOTIFY messages that 
subnot-etags is allows to suppress.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 18:36:42 -0500

On 4/6/10 17:46, Apr 6, Brett Tate wrote:
> It works okay excluding the non backward compatibility with RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)...

I don't think it's accurate to characterize the change as 
non-backwards-compatible. The only wire-visible behavior that one could 
conceivable observe is that a subscriber might make a different decision 
about which subscription to accept if the SUBSCRIBE forks and the 
subscriber wants only one subscription.

What we *do* gain is a simplification for implementors. Because the 
behavior of establishing the dialog when a NOTIFY shows up (instead of 
"the first of a 2xx or a NOTIFY) is much easier to code, people will 
make fewer mistakes, and have fewer bugs. But you'd be hard pressed to 
see a difference on the wire.

> The draft's Timer N (and lack of related NOTIFY) text is potentially 
> worded in a way which does not require the tear down (and non 
> creation) of subscription.

Tear-down of existing dialogs is still an open issue, sure. I don't get 
where you see any wiggle room in what happens if Timer N fires for the 
first SUBSCRIBE/NOTIFY exchange.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 07:33:35 +0200

Hi, 

>>>>In any case, proxies don't inherently care about subscription state. 
>>>>If you're doing something in your proxy that is attempting to figure 
>>>>out the state of a subscription, you need to take care to 
>>>>figure out what's going on. In that case, yeah, Timer N is going to 
>>>>be of interest to you.
>>>The draft says that proxies no not need to support 
>>>anything in addition to 3261, so from that point of view you 
>>>are correct.
>>>
>>>However, at the same time it talks about proxies adding 
>>>Record-Route if they are interested in the SUBs and NOTs, so 
>>>I assumed that means that they are "allowed" to actually 
>>>maintain subscription dialog state - in the same way as they 
>>>might maintain invite dialog state.
>>> Even if a proxy is keeping subscription-state information, I don't 
>>> see Timer N introducing a problem.  The proxy sees all the 
>>> SUBSCRIBEs and NOTIFYs and their responses.  Under 3265bis, 
>>> the NOTIFYs, actually, the the *responses* to the NOTIFYs 
>>> show all of the subscription state.  In particular, in 
>>> seciton 4.1.2.4, I see:
>>>
>The subnot-etags document explicitly does not allow 
>suppression of initial NOTIFY messages. They are critical to 
>establishing a dialog.
>
>The text Dale cites relates exclusively to handling of 
>*initial* NOTIFYs. It is unrelated to the kinds of NOTIFY 
>messages that subnot-etags is allows to suppress.

Correct. I've been trying to say that, but I appologise if it didn't apply to Dale's case.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 08:20:38 +0200

Hi,

I haven't double checked whether it is said in 3265bis, but we also need to make clear whether it is the NOTIFY request, or the NOT 200 response, that "acknowledges" the (re-)subscription.

Because, a NOTIFY request can also be rejected (e.g. due to overload), so in order to avoid sub state unsynch every entity in the path needs to know what a NOT non-200 response means.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 7. huhtikuuta 2010 2:37
> To: Brett Tate
> Cc: SIPCORE
> >> Is there *any* problem here? This seems to be working 
> about as well 
> >> as anyone might hope.
> >>      
> > It works okay excluding the non backward compatibility with 
> RFC 3265 (concerning SUBSCRIBE's 2xx response impacts)...
> 
> non-backwards-compatible. The only wire-visible behavior that 
> one could conceivable observe is that a subscriber might make 
> a different decision about which subscription to accept if 
> the SUBSCRIBE forks and the subscriber wants only one subscription.
> 
> What we *do* gain is a simplification for implementors. 
> Because the behavior of establishing the dialog when a NOTIFY 
> shows up (instead of "the first of a 2xx or a NOTIFY) is much 
> easier to code, people will make fewer mistakes, and have 
> fewer bugs. But you'd be hard pressed to see a difference on the wire.
> 
> Tear-down of existing dialogs is still an open issue, sure. I 
> don't get where you see any wiggle room in what happens if 
> Timer N fires for the first SUBSCRIBE/NOTIFY exchange.
> 
> /a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 08:27:22 +0200

Hi, 

>>>Is there *any* problem here? This seems to be working about as well 
>>>as anyone might hope.
>>>      

I agree with Adam.

Of course, for resubscriptions we don't have the forking issue, but I still think we should have the same behavior, ie the NOTIFY acknowledges the resub.

...and, again, that is why I have an issue with allowing the suppression of NOTIFYs. It's not a problem for endpoints, but for stateful intermediaries (proxies ARE allowed to Record-Route SUB requests, so)

>Timer N fires for the first SUBSCRIBE/NOTIFY exchange.

For the initial SUB/NOT, I think that tearing down the dialog is the only thing you can do.

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Wed, 7 Apr 2010 05:08:16 -0700

> Sent: Tuesday, April 06, 2010 7:37 PM
> To: Brett Tate
> Cc: Paul Kyzivat; SIPCORE
> > It works okay excluding the non backward compatibility with RFC 3265
> (concerning SUBSCRIBE's 2xx response impacts)...
> 
> non-backwards-compatible.

RFC 3265 section 3.3.4 indicates that 2xx "creates a new subscription and a new dialog"; rfc3265bis does not allow such a thing.

3.3.4. Dialog creation and termination

   If an initial SUBSCRIBE request is not sent on a pre-existing dialog,
   the subscriber will wait for a response to the SUBSCRIBE request or a
   matching NOTIFY.

   Responses are matched to such SUBSCRIBE requests if they contain the
   same the same "Call-ID", the same "From" header "tag", and the same
   "CSeq".  Rules for the comparison of these headers are described in
   SIP [1].  If a 200-class response matches such a SUBSCRIBE request,
   it creates a new subscription and a new dialog (unless they have
   already been created by a matching NOTIFY request; see below).

<snip>

> first SUBSCRIBE/NOTIFY exchange.

That is the issue... as currently worded, there is no "wiggle room".  Thus a vendor that wants to implement rfc3265bis can't also remain compatible with rfc3265 devices.  And if a vendor wants to use a value other than 64*T1 for Timer N, rfc3265bis doesn't appear to allow it.

Timer N has its use.  Depending upon the dialog package, some vendors implement Timer N to be extremely low (such as 2-5 seconds).  For other packages, they apply Timer N (with value similar to rfc3265bis) only to dialogs being created by NOTIFY; they allow the SUBSCRIBE 2xx's Expires to be Timer N value for the associated dialog.

I actually don't have strong opinion concerning all of this.  I raised the issue mainly because the divergence from rfc3265 appears to work worse during overload situations and because frequent subscription creation/removal (such as because Timer N expiration) can lead to or prolong overload.

---

From: Brett Tate <[email-masked]>
Date: Wed, 7 Apr 2010 05:26:39 -0700

> Then what would happen in a polling subscribe (Expires:0) if 
> the 200 is received and the NOTIFY is not received? How long 
> should you wait before giving up? ISTM you still need timer-N 
> to tell you it failed, so you can give up waiting.

I agree that you need a Timer N (or something like it); however Timer N should not be restricted to 64*T1.  The rfc3265bis should accommodate other Timer N values instead being restricted to 64*T1 for all event packages, deployments, situations, etcetera.

Concerning the polling/fetch (Expires: 0), it might actually be useful to communicate within SUBSCRIBE how long you are willing to wait for the NOTIFY.  For instance, there are some situation where I'm willing to wait 1-2 seconds; there are other situations where I'm will wait more than 64*T1 if received 2xx response.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 11:17:31 -0400

[as individual]

> ...and, again, that is why I have an issue with allowing the suppression of NOTIFYs. It's not a problem for endpoints, but for stateful intermediaries (proxies ARE allowed to Record-Route SUB reque…

I think you just explained why NOTIFY should *not* ack the resub.

The response to the reSUBSCRIBE is important, to the transaction, and to 
the subscribe usage status.

Timer-N *could* still apply to the resulting NOTIFY, if one is expected, 
and the subscriber would then need to consider the usage broken if it 
isn't received. But in that case I think it would need to send another 
reSUBSCRIBE with Expires:0 to terminate the subscription - which would 
satisfy any intermediaries that were otherwise confused.

Whether applying timer-N to resubscribes is a *good* thing is not 
immediately clear to me. If the resubscribe is just intended as a 
refresh, then having to time it is an inconvenience. OTOH, if the 
resubscribe is a poll, or a way to change the filter in effect, then the 
immediate notify is probably desired.

One think I noted when checking the bis on this is that the state 
diagram doesn't mention 408 responses. I think it should initiate a 
teardown of the usage.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 19:21:44 +0200

Hi,

>I think you just explained why NOTIFY should *not* ack the resub.

Sure, if the SUB 200 response acks the resub, there should be no problem.

I just assumed that the NOT request (or response) would ack also resubs, to make the state machine consistant with initial subs. But, if that is not the case, we need to make it VERY clear in 3265bis.

>The response to the reSUBSCRIBE is important, to the transaction, and to the subscribe usage status.
>

That could work.

>immediate notify is probably desired.

I guess it would be good to be able to indicate whether an immediate notify is required, in such indicator could start timer-N. But, all entities would of course have to understand such indicator.

Regards,

Christer

        Thanks,
        Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Apr 2010 13:13:38 -0500

[as individual]

> diagram doesn't mention 408 responses. I think it should initiate a 

408 responses aren't allowed for non-invite transactions.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 14:29:02 -0400

[as individual]

> 408 responses aren't allowed for non-invite transactions.

Huh???

Of course they are. Any request can time out.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 7 Apr 2010 11:32:58 -0700

I assume that Adam is referring to RFC 4320.  However as discussed within the following thread, the 408's can still be received.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-April/024774.html 

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 2:29 PM
> To: Adam Roach

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Apr 2010 13:36:14 -0500

> Of course they are. Any request can time out.

RFC 4320, section 4.2: "A transaction-stateful SIP element MUST NOT send 
a response with Status-Code of 408 to a non-INVITE request." The 
rationale for this normative update to 3261 is given in section 1.4 of 
RFC 4321.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 14:52:15 -0400

[as individual]

Sorry. Perhaps I was being imprecise. I'm used to talking about 
receiving a 408 as synonymous with "receiving a 408 or having the 
transaction time out". Some stacks will return a 408 as a result of 
timeout even though one was never received.

The point remains - if some transaction in the usage times out, and the 
presumption is that the usage is then dead, I think its expected that 
there will still be signaling to indicate its being torn down, isn't 
there? Assuming this happens to the subscriber, shouldn't it send a 
reSUBSCRIBE with Expires:0 to explicitly terminate it. (Just as a BYE 
would be sent if this happened within an INVITE usage.)

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Apr 2010 03:16:16 +0200

While I accept that RFC 4320 is mandatory for all current implementations calling themselves SIP, we do need to deal with compatibility issues with deployments made before it was thought of and became an RFC.

Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any other implementation needs to be able to receive it.

Unless of course you can argue that any entity sending it in the first place had to be so broken that it is otherwise inoperable. 

regards

Keith

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, April 07, 2010 7:52 PM
> To: Adam Roach
> Cc: SIPCORE
> Sorry. Perhaps I was being imprecise. I'm used to talking 
> about receiving a 408 as synonymous with "receiving a 408 or 
> having the transaction time out". Some stacks will return a 
> 408 as a result of timeout even though one was never received.
> 
> The point remains - if some transaction in the usage times 
> out, and the presumption is that the usage is then dead, I 
> think its expected that there will still be signaling to 
> indicate its being torn down, isn't there? Assuming this 
> happens to the subscriber, shouldn't it send a reSUBSCRIBE 
> with Expires:0 to explicitly terminate it. (Just as a BYE 
> > RFC 4320, section 4.2: "A transaction-stateful SIP element MUST NOT 
> > send a response with Status-Code of 408 to a non-INVITE 
> request." The

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Apr 2010 22:36:42 -0500

> Thus if an RFC 3261/3265 sans RFC 4320 can send a 408 response, then any other implementation needs to be able to receive it.

Be able to receive it, yes. But, as RFC 4321 explains, the local 
transaction timer will have already expired. The 408 will be treated as 
a stray response. A well-designed SIP stack will discard it before it 
even reaches the TU. Even a poorly-designed but 3261-compliant 
application will ignore a 408 for a non-INVITE, because the transaction 
is already gone.

In other words, by the time the 408 arrives, it is thoroughly 
irrelevant. We don't need to talk about it in 3265bis, because something 
else will have gone wrong first.

And that situation is already covered:

    If the NOTIFY request fails due to expiration of SIP Timer F
    (transaction timeout), the notifier SHOULD remove the subscription.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 08:46:20 +0200

Hi,

In the case of DE-subscriptions (which is just one variant of re-subscription), I still think there are some issues regarding whether the SUB 200 or the NOT req acknowledges the SUB req.

Assuming the sub dialog is terminated when an entity receives a SUB 200 that contains 'Expires: 0'.

Now, if there is then a NOT request (that contains 'Subscription-State: terminated'), won't it be treated as an out-of-dialog request, and rejected?

(Again, IF one is supposed to wait for the NOT req before terminating the dialog we again have a problem with the subnot draft.)

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 7. huhtikuuta 2010 9:21
> To: Adam Roach; Brett Tate
> Cc: SIPCORE
> Subject: [sipcore] Rfc3265bis: NOTIFY request or response 
> confirms (re-)subscription? [was rfc3265bis: SIP events redux 
> [was Minutes Posted]]
> 
> 
> Hi,
> 
> I haven't double checked whether it is said in 3265bis, but 
> we also need to make clear whether it is the NOTIFY request, 
> or the NOT 200 response, that "acknowledges" the (re-)subscription.
> 
> Because, a NOTIFY request can also be rejected (e.g. due to 
> overload), so in order to avoid sub state unsynch every 
> entity in the path needs to know what a NOT non-200 response means.
> 
> Regards,
> 
> Christer
> 
> 
>  
> 
> > non-backwards-compatible. The only wire-visible behavior that one 
> > could conceivable observe is that a subscriber might make a 
> different 
> > decision about which subscription to accept if the 
> SUBSCRIBE forks and 
> > the subscriber wants only one subscription.
> > 
> > Because the behavior of establishing the dialog when a 
> NOTIFY shows up 
> > (instead of "the first of a 2xx or a NOTIFY) is much easier 
> to code, 
> > people will make fewer mistakes, and have fewer bugs. But you'd be 
> > hard pressed to see a difference on the wire.
> > 
> > Tear-down of existing dialogs is still an open issue, sure. I don't 
> > get where you see any wiggle room in what happens if Timer 
> N fires for 
> > the first SUBSCRIBE/NOTIFY exchange.
> > 
> > /a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 08:48:09 +0200

Hi,

Also, both 3265 and 3265bis contains the following text:

"A subscriber may send a SUBSCRIBE request with an "Expires" header
field of 0 in order to trigger the sending of such a NOTIFY
request; however, for the purposes of subscription and dialog
lifetime, the subscription is not considered terminated until the
NOTIFY transaction with a "Subscription-State" of "terminated"
completes."

Regards,

Christer

> Sent: 8. huhtikuuta 2010 9:46
> To: [email-masked]
> Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response 
> In the case of DE-subscriptions (which is just one variant of 
> re-subscription), I still think there are some issues 
> regarding whether the SUB 200 or the NOT req acknowledges the SUB req.
> 
> Now, if there is then a NOT request (that contains 
> 'Subscription-State: terminated'), won't it be treated as an 
> out-of-dialog request, and rejected?
> 
> (Again, IF one is supposed to wait for the NOT req before 
> terminating the dialog we again have a problem with the subnot draft.)
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
>  
> 
> > Subject: [sipcore] Rfc3265bis: NOTIFY request or response confirms 
> > (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes 
> > Posted]]
> > 
> > 
> > Hi,
> > 
> > I haven't double checked whether it is said in 3265bis, but we also 
> > need to make clear whether it is the NOTIFY request, or the NOT 200 
> > response, that "acknowledges" the (re-)subscription.
> > 
> overload), 
> > so in order to avoid sub state unsynch every entity in the 
> path needs 
> > to know what a NOT non-200 response means.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >  
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 10:17:47 -0400

[as individual]

> Now, if there is then a NOT request (that contains 'Subscription-State: terminated'), won't it be treated as an out-of-dialog request, and rejected?

That scenario has always bothered me. When my purpose is simply to 
request the termination of the existing dialog, and I have no further 
interest in the state, is there any reason for the NOTIFY? Can it be 
suppressed? Its especially a problem if I think the dialog is already 
broken, and I'm just trying to ensure its cleanly gone.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Apr 2010 16:49:18 +0200

Your argument is accepted.

That is an appropriate compatibility analysis.

Keith

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 4:37 AM
To: DRAGE, Keith (Keith)
Cc: Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] rfc3265bis: SIP events redux [was Minutes Posted]

Be able to receive it, yes. But, as RFC 4321 explains, the local transaction timer will have already expired. The 408 will be treated as a stray response. A well-designed SIP stack will discard it before it even reaches the TU. Even a poorly-designed but 3261-compliant application will ignore a 408 for a non-INVITE, because the transaction is already gone.

In other words, by the time the 408 arrives, it is thoroughly irrelevant. We don't need to talk about it in 3265bis, because something else will have gone wrong first.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 13:06:53 -0500

> RFC 3265 section 3.3.4 indicates that 2xx "creates a new subscription and a new dialog"; rfc3265bis does not allow such a thing.

Yes, it's a *change*, but it's a *backwards* *compatible* change.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 13:11:00 -0500

> I agree that you need a Timer N (or something like it); however Timer N should not be restricted to 64*T1.  The rfc3265bis should accommodate other Timer N values instead being restricted to 64*T1…

Sure, we can enter into a discussion of how to set Timer N. But, to fix 
the problems that we had in 3265, any changes really need to be 
predicated on two qualities:

   1. Everyone involved in the transaction needs to know what value
      Timer N has -- otherwise, you can easily end up with differing
      ideas of dialog and subscription state.

   2. Variation in Timer N can't be based on a mechanism to withhold the
      initial NOTIFY message for an arbitrary (or even a relatively
      long) period of time. NOTIFY is an important part of the 3-way
      handshake used to set up a dialog, and extensions can reasonable
      make assumptions around this completing in a reasonable amount of
      time (3265 defines this as "immediately").

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 13:14:42 -0500

> NOTIFY transaction with a "Subscription-State" of "terminated"

Yes. The fixes to specifically accommodate subnot-etags are not in the 
current version of the document. This will all be addressed in a future 
version of the draft.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 13:29:14 -0500

[as individual]

On 4/8/10 9:17 AM, Paul Kyzivat wrote:
>> re-subscription), I still think there are some issues regarding 
>> whether the SUB 200 or the NOT req acknowledges the SUB req.
>>
> suppressed?

Yes. RFC 5839 (which will be published shortly) -- more widely known as 
subnot-etags -- will provide exactly the mechanism to perform this 
suppression.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 21:31:54 +0200

Hi,

>subnot-etags -- will provide exactly the mechanism to perform this

But again, stateful intermediaries that do not support subnot will wait for the NOTIFY.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 15:57:39 -0400

[as individual]

Its good that subnot-etags will help with this.
But support for that will be optional, and it may not even make sense 
for some event packages. Yet not wanting the notify when ending the 
subscription can make sense for all event packages.

Is there a way that packages that support subnot-etags just for the "I 
don't want to see anything" case, without the complexity and bother of 
supporting for anything else?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 08 Apr 2010 15:02:24 -0500

[as individual]

On 4/8/10 2:57 PM, Paul Kyzivat wrote:
> But support for that will be optional...

Which is pretty much true of anything we define after the fact. Horses 
have left the barn, etc.

> ...and it may not even make sense for some event packages.

I think you'll have a hard time coming up with an example of an entire 
event package for which etags doesn't make sense.

> supporting for anything else?

Not for the server. The client can blindly do a "Suppress-If-Match: *" 
on unsubscribe and not worry about the etag mechanism otherwise.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 16:13:39 -0400

[as individual]

> But again, stateful intermediaries that do not support subnot will wait for the NOTIFY.

Are you aware of any *proxies* that are dialog stateful for sub/not?
(Its not an issue for B2BUAs since they must support it for the two ends 
to use it.)

If so, is there really some good reason for them to be doing so?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 22:13:45 +0200

Hi,

IF we in 3265bis are going to say (see earlier discussion) that the SUB 200 (rather than the NOT) acknowledges a RE-subscription, is there are reason why we can't say the same thing for a DE-subscription?

Regards,

Christer

________________________________________
From: Adam Roach [[email-masked]]
Sent: Thursday, April 08, 2010 11:02 PM
To: Paul Kyzivat
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] Rfc3265bis: NOTIFY request or response confirms (re-)subscription? [was rfc3265bis: SIP events redux [was Minutes Posted]]

[as individual]

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Apr 2010 22:21:08 +0200

Hi,

>Are you aware of any *proxies* that are dialog stateful for sub/not?

Yes, I am. They insert Record-Route (which is explicitly allowed), and maintain the subscription dialog state.

>(Its not an issue for B2BUAs since they must support it for the two ends to use it.)

Correct. I am talking about proxies.

>If so, is there really some good reason for them to be doing so?

That information I unfortunately don't have at the moment.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 16:24:24 -0400

> event package for which etags doesn't make sense.

I'm no expert on this, but its my impression that it is *work* for the 
server developer to assign etags and then handle the suppression based 
on them. I'm thinking a lot of implementors would rather not bother to 
do that, and will only do so if the event package spec says they must. 
(Which none of the current ones do.)

Can a server never send etags in NOTIFY, yet still support 
"Suppress-If-Match: *" in SUBSCRIBE?

	Thanks,
	Paul