Subject: [Sip] Comment on refer-with-norefersub-01

From: Cullen Jennings <[email-masked]>
Date: Wed, 02 Mar 2005 21:43:07 -0800

It seems like in any case where you put a Require with the option tag, it
results in far more traffic and less chance of interoperability than
creating the subscription and instantly ending it.

I think you should say that the tag is not allowed in a Require.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Tom Hiller <[email-masked]>
Date: Thu, 03 Mar 2005 03:19:04 -0600

Cullen,

Does this mean the mobile has to receive an immediate notification due 
the REFER, then send a SUBSCRIBE to kill the implicit subscription, and 
then get yet another notification?

In practice, people draw message flows, count SIP requests and responses 
and other messages on a per "call" basis, and then tally a total. In 
wireless it is sometimes important to minimize the number of messages 
per "call".  "norefersub" reduces the number of messages when one 
doesn't need the implicit subscription because the user learns the 
notification information via existing subscriptions or via other ways.

Also, some wireless spectrum is costly, and in some cases there is a 
potential for lengthy SIP notification packets to interfere with RTP 
packet flow due to lack of over-the-air connection bandwidth. There is 
also a possible service impact of not being able transmit another 
message while sending a SUBSCRIBE to instantly end a subscription.

OMA has extensively incorporated "norefersub" into draft baselines 
(i.e., includes the option tag "norefersub" in the Require header). 
These draft baselines are now being readied for publication.  OMA 
requires the "norefersub" option tag in the Require header.

If I am misunderstanding the point of your comment, could you expand 
further?

	- Tom

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 20:37:35 -0800

I think your are misunderstanding. I don't think it means this at all

It means the UAC sends it with the tag but no require. If UAS supports it,
great. If the UAS does not support it then the refer still works and a
NOTIFY is sent which the UAC promptly ends.

Now consider what would have happened if we did have the require.

UAC would send the refer, it would fail. The the UAC would send refer
without the tag. Then the UAS would send Notify, then the UAC would cancel
the subscription. 

It seems the first is case better for wireless - what am I missing here.

---

From: Adam Roach <[email-masked]>
Date: Sun, 06 Mar 2005 01:15:47 -0600

Tom Hiller wrote:

> the REFER, then send a SUBSCRIBE to kill the implicit subscription, 
> and then get yet another notification?

No; if you read REFER, the preferred method of killing the subscription 
is to send a 481 response to the first NOTIFY.

/a

---

From: Adam Roach <[email-masked]>
Date: Sun, 06 Mar 2005 01:21:23 -0600

Whoops; I spoke too quickly. I thought this was documented in REFER; 
apparently, it's just something we spoke about putting in there, but it 
must not have made the final cut.

Anyway, the general flow (prior to the norefersub extension) for a 
terminal that didn't care about the subscription is something like:

|--REFER-->|
|<---2xx---|
|<-NOTIFY--|
|----481-->| Kills subscription; see section 3.2.2 of RFC 3265

/a

Adam Roach wrote:

> Tom Hiller wrote:
>
>> Does this mean the mobile has to receive an immediate notification 
>> due the REFER, then send a SUBSCRIBE to kill the implicit 
>> subscription, and then get yet another notification?
>
>
>
> No; if you read REFER, the preferred method of killing the 
> subscription is to send a 481 response to the first NOTIFY.
>
> /a
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Mar 2005 11:46:22 -0500

Interesting; I have argued that it doesn't belong in Supported either. 
The reason is that supported just means, "hey, I understand this 
extension, in case you may want to use it". It does not mean, "I want 
you to exhibit behavior X, but are not requiring you to do it". 
Generally, I think the decision about whether or not the subscription is 
created is to be chosen by the entity sending the REFER; that is the 
point of this spec. If that is the case, it is not appropriate to put 
the option tag into Supported.

The closest thing to "I want you to exihibit behavior X, but are not 
requiring you to do it", is to define a header field that describes the 
behavior:

CreateSub: yes

and then have no Require header for this if it can be safely ignored, 
which as Cullen is arguing is better for wireless.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Mar 2005 12:50:39 -0600

The original proposal was indeed to _REQUIRE_ that no subscription be 
created.
This is what we built this extensibility mechanism for - the extra 
round trip it comes
with _IF_ you are willing to accept the REFER with a subscription is 
the cost of
the extensibility mechanism we defined (Cullen's objection is based on 
the assumption
that you always will).

RjS

On Mar 7, 2005, at 10:46 AM, Jonathan Rosenberg wrote:

> Generally, I think the decision about whether or not the subscription 
> is created is to be chosen by the entity sending the REFER; that is 
> the point of this spec. If that is the case, it is not appropriate to 
> put the option tag into Supported.
>
> requiring you to do it", is to define a header field that describes 
> the behavior:
>
> CreateSub: yes
>