Subject: [sipcore] (Info event) Questions about Willingness and Capability negotiation

From: Linyi TIAN <[email-masked]>
Date: Fri, 25 Sep 2009 11:14:26 +0800

Hi, Experts

When I further dig the SIP INFO Event I-D, one thing puzzled me is the
willingness and capability negotiation (Recv-Info header).

In section 4.1

(Paragraph 5) The UAC may send INFO requests once the UAS has sent the
Recv-Info header field value, indicating what the UAS supports.

[Linyi] Here it says "MAY send" and "indicate it supports" rather than
Willingness.

In section 3.2 

(Paragraph 3) If the UAC receives a Recv-Info header with the value 'nil',
the UAC

   MUST NOT send any INFO methods that contain Info Packages.

(Paragraph 7) The presence of the Recv-Info header in a message is
sufficient to indicate support for this version of INFO.

[Linyi] From the first bullet it is clear that Recv-Info is used to indicate
willingness. It is also used to indicate for support INFO package and
framework.

In section 4.1:

(Paragraph 3) In this case, if the UAS has never offered a Recv-Info header
or never offered a Recv-Info header with a package of a similar function to
the legacy INFO usage, the UAC MAY send an INFO without an Info-Package
header field and a body appropriate to the said legacy usage.

[Linyi] Is it possible to send Info Package without Recv-Info? I have a use
case as follows. For example, if the UAS wants to perform
Configuration/Administration task on the UAC it can send Info Package at any
time without the UAC indicating whether it wants to be configured. In this
case if the UAC does not support the Info Package it can return appropriate
SIP error code. 

       Then the SIP code will be used to indicate whether UAC supports the
new SIP INFO method. Recv-Info will be used to indicate the willingness
whether it wants to receive the package. The two mechanisms will be
separated and could be used appropriately depending on the use cases.

In section 3.2

(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO package
until the UAC receives an "INVITE dialog usage" request or response (for

   session establishment or target refresh) with a Recv-Info header listing
the given Info Package.

[Linyi] I don't see strong reason to bundle them together. Here is my view
and proposal:

The I-D introduce three things: 

1.    SIP INFO Package (new SIP INFO method) to replace old SIP INFO method

2.    SIP INFO Framework which provides a negotiation mechanism via
Recv-Info header in SIP INVITE, Update, Re-INVITE to indicate the
willingness to receive packages

3. Use appropriate SIP code to indicate whether UAC supports a specific Info
package

SIP INFO Package can be used independently with SIP INFO Framework. 

By using this approach, we still have solve the IOP issues for old SIP INFO
and good mechanism for negotiation of Capability and Willingness. It will
accelerate the adoption of new SIP INFO method and provides smooth migration
path for old SIP INFO methods to be moved to new one.

I am looking forward to your expert comments and feedback.

Cheers,

Linyi

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 25 Sep 2009 07:59:15 +0200

Hi, 

Willingness.

We have received the same comments from others, and in the next version
it will talk about "willingness to receive".

>In section 3.2 
>
>(Paragraph 3) If the UAC receives a Recv-Info header with the value
'nil', the UAC MUST NOT send any INFO methods that contain Info
Packages.
>
>[Linyi] From the first bullet it is clear that Recv-Info is used to
indicate willingness. It is also used to indicate for support INFO
package and framework.

Yes.

>In section 4.1:
>
>(Paragraph 3) In this case, if the UAS has never offered a Recv-Info
header or never offered a Recv-Info header with a package of a similar
function to the legacy INFO usage, the UAC MAY send 
>an INFO without an Info-Package header field and a body appropriate to
the said legacy usage.

Yes.

>[Linyi] Is it possible to send Info Package without Recv-Info? I have a
use case as follows. For example, if the UAS wants to perform
Configuration/Administration task on the UAC it can send 
>Info Package at any time without the UAC indicating whether it wants to
be configured. In this case if the UAC does not support the Info Package
it can return appropriate SIP error code. 
>
>Then the SIP code will be used to indicate whether UAC supports the new
SIP INFO method. Recv-Info will be used to indicate the willingness
whether it wants to receive the package. The two 
>mechanisms will be separated and could be used appropriately depending
on the use cases.

The idea is that Info Packages are sent ONLY if the other party has
indicated willingess to receive them (which at the same time is an
indication that your support the I-P mechanism).

Again, that is one of the main purpose of I-P: to be able to explicitly
indciate what you want to receive, instead of relying on assumptions,
static configurations etc.
	
>In section 3.2
>
>(Paragraph 1) A UAC MUST NOT send INFO requests for a given INFO
package until the UAC receives an "INVITE dialog usage" request or
response (for session establishment or target refresh) with a 
>Recv-Info header listing the given Info Package.
>
>[Linyi] I don't see strong reason to bundle them together. Here is my
>
>3. 	 Use appropriate SIP code to indicate whether UAC supports a
specific Info package

You use Recv-Info to indicate what you are willing to receive. I see no
reason why you then should send some other I-P (you are still allowed to
use legacy INFOs, for which there are no I-Ps)

>SIP INFO Package can be used independently with SIP INFO Framework. 

SIP I-P IS part of the framework.

>By using this approach, we still have solve the IOP issues for old SIP
INFO and good mechanism for negotiation of Capability and Willingness.
It will accelerate the adoption of new SIP INFO 
>method and provides smooth migration path for old SIP INFO methods to
be moved to new one.

I don't see how it will accelerate anything - I think it will confuse
people even more... If you implement support of an I-P, I don't think it
is that much extra to implement support of the Recv-Info header.

Regards,

Christer

---

From: Linyi TIAN <[email-masked]>
Date: Fri, 25 Sep 2009 15:16:16 +0800

I agree Recv-Info is perfect for indicating the willingness. But it looks
strange to use Recv-Info header to indicate the capability support. I guess
it is better to be indicated using SIP code. 

For the case I described, if the UAS wants to perform some application level
configuration/administration task, it can send the INFO package directly
without receiving Recv-Info header from UAC. 

What I mean is that in this approach SIP INFO package can be used
independently with Recv-Info. If the use case needs to negotiate the
willingness then use them together. If no willingness needed then use new
SIP INFO method alone. Does it make sense?

Cheers,
Linyi

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, September 25, 2009 1:59 PM
To: Linyi TIAN; SIPCORE
Subject: RE: [sipcore] (Info event) Questions about Willingness and
Capabilitynegotiation

Hi, 

Willingness.

Yes.

the said legacy usage.

Yes.

on the use cases.

	
specific Info package

be moved to new one.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 25 Sep 2009 12:28:26 +0200

Hi, 

>I agree Recv-Info is perfect for indicating the willingness. 
>But it looks strange to use Recv-Info header to indicate the 
>capability support. I guess it is better to be indicated 
>using SIP code. 

There IS an error code, 469, which is used if one receives an IP which
it does not support (or want to receive). BUT, that error code is for
error/race-condition cases - it is NOT a genral mechanism to figure out
what the other is willing to receive. 

>For the case I described, if the UAS wants to perform some 
>application level configuration/administration task, it can 
>send the INFO package directly without receiving Recv-Info 
>header from UAC. 

Why can't the UAC indicate willingess to receive the conf/adm package,
if it supports it????

Again, there is a reason for having Recv-Info, and that is to avoid
sending of stuff which the other does not support.

Based on your proposal, it is ok to use I-Ps even if the remote party
hasn't indicated willingess to receive them, and that is very confusing
in my opinion - and it's bad protocol design. 

>What I mean is that in this approach SIP INFO package can be 
>used independently with Recv-Info. If the use case needs to 
>negotiate the willingness then use them together. If no 
>willingness needed then use new SIP INFO method alone. Does 
>it make sense?

No, at least not in my ears.

We have had lenghty discussions about this, and I would not like to
change it unless you can show that what we have now doesn't work. But,
as always, if the group decides to do as you propose, I will of course
accept it.

Regards,

Christer

> Subject: RE: [sipcore] (Info event) Questions about 
> Willingness and Capabilitynegotiation
> 
> 
> Hi, 
> 	 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 25 Sep 2009 17:52:42 -0500

On Sep 25, 2009, at 2:16 AM, Linyi TIAN wrote:

> application level

I'm pretty sure I don't understand, so no, it doesn't make sense to me  
yet.

--
Dean

---

From: Linyi TIAN <[email-masked]>
Date: Sun, 27 Sep 2009 08:46:54 +0800

Hi, Christer

There is a discussion in OIPF about the Timer Configuration. You can ask
George about the background. 

In 3GPP solution if a SIP INVITE is sent from UAC, the UAS can send one XML
document within SIP 200 OK to change the timer. We think this is a simple
mechanism. On the other hand this is a configuration and administration task
which does not need the UAC to indicate the willingness to be configured. It
should be always available. 

If Recv-Info header can be decoupled with new SIP INFO, it could be ok to
use it for this function. 

Timer modification function should be always available which means the UAC
always support it. It does not require the UAC to indicate it supports using
Recv-Info nor indicate it is willing to be changed. 

Therefore we believe for this function it is abusing the SIP INFO framework.
It will also cause different implementation in TISPAN/3GPP/OIPF.

We are not saying any SDO should not support SIP INFO framework. We do see
benefit for this I-D but that does not necessary mean we should use it
everywhere and abuse it. It should depend on the use cases. 

However this discussion is better to be done in other SDOs.

In IETF, the current draft is really confusing about capability support and
indicating willingness. Recv-Info header is used to indicate the support for
SIP INFO framework. It is also used to indicate willingness. The error 469
was for that purpose as well. We think two concepts are not the same and
should be clearly described.

Cheers,
Linyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Friday, September 25, 2009 6:28 PM
To: Linyi TIAN; SIPCORE
Subject: Re: [sipcore] (Info event) Questions about Willingness and
Capabilitynegotiation

Hi, 

Regards,

Christer

> is that much extra to implement support of the Recv-Info header.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Linyi TIAN <[email-masked]>
Date: Sun, 27 Sep 2009 09:00:36 +0800

Both Recv-Info and 469 was used to indicate capability support and
willingness. That was confusing thing.

If Recv-Info is only used to indicate willingness there would be several
scenarios:
1. UAC indicates willingness to receive INFO package by Recv-Info, then UAS
sends INFO.
2. UAC indicates 'nil' in Recv-Info, then UAS MUST NOT send INFO.
3. UAC didn't send Recv-Info but the UAS wants to send SIP INFO. In this
case if UAC supports and would like to consume it then it will be ok. If it
does not support, return 415 (or 469??) . If it supports but doesn't want to
consume it, return 469 as appropriate.

Would this be better?

Cheers,
Linyi

-----Original Message-----

Hi, 

Willingness.

Yes.

the said legacy usage.

Yes.

on the use cases.

	
specific Info package

be moved to new one.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Sat, 26 Sep 2009 20:59:58 -0500

> should be always available.

I have to say Huh? If I understand the approach, it's about the  
strangest mechanism I can imagine. It's pretty much a violation of  
every SIP extensibility principle every discussed.

Also, adding bodythings to response messages is a bad idea (read:  
pretty much completely forbidden) because we have no way to manage  
size and fragmentation on responses delivered over UDP.

> use it for this function.

You mean you want to use Recv-Info in the INVITE request to tell the  
UAS it can send a special XML body back in the 200 OK?
> Recv-Info nor indicate it is willing to be changed.

Why would a UAC always support it? Not a single one of the UAs I  
currently have supports it.  It seems like a totally proprietary hack  
that only a few 3GPP-compliant UAs would support. Definitely the kind  
of thing that requires feature negotiation.

...

> should be clearly described.

469 is a dialog-terminating error condition. It's much better to just  
not send the offending message because you know the other end isn't  
capable and willing than it is to make your dialog explode and die.

--
Dean

---

From: Linyi TIAN <[email-masked]>
Date: Sun, 27 Sep 2009 11:08:25 +0800

Surprised to see you still working in Sunday. We work today because we
switch one day for Chinese National Holiday:)

Thanks for the guidance. This discussion is better to be directly to 3GPP or
other SDOs. Let's continue the discussion on I-D itself. See inline
response.

Cheers,
Linyi

> From: Dean Willis [mailto:[email-masked]]
> Sent: Sunday, September 27, 2009 10:00 AM
> To: Linyi TIAN
> Cc: 'Christer Holmberg'; 'SIPCORE'
 
> of thing that requires feature negotiation.

[Linyi TIAN] Yes, it only works for 3GPP-compliant UAs. I mean in that
context we already knows UA supports it why bother to send capability
indication? For this administration function, I also don't see the need to
show willingness. Why the UAC wants to say I don't want to be configured?

I will wait to see the new version of the I-D before I post any new
comments. For the time being, I understand what you mean. However I still
think mixing the concepts between Capability Support and Willingness is not
a good idea.

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 27 Sep 2009 13:55:55 +0200

Hi,

>Both Recv-Info and 469 was used to indicate capability support and willingness. That was confusing thing.
 
Why is that confusing??? We have a header to indicate what one is willing to receive, and we have a response code to indicate that something is not accepted. That's nothing new in SIP...

Yes.

Yes.

>consume it, return 469 as appropriate.
 
If the UAC supports and wants to consume it should indicate so using Recv-Info. I don't see what the problem with that is...
 
Since the I-P spec defines both the I-P concept and the Recv-Info header, there are no implementations out there which support Info Packages, but not Recv-Info. So, if you implement support of a I-P you also implement support of Recv-Info. 
 
It's the same reason why we have the Supported header. A UAS shall not use an extension towards the UAC if the UAC hasn't indicated support using an option-tag.
 
It's the same reason why we indicate codecs in the SDP. A UAS shall send use a codec towards the UAC which the UAC hasn't indiated support for.
 
etc.
 
Regards,
 
Christer

-----Original Message-----

Hi,

Willingness.

Yes.

the said legacy usage.

Yes.

on the use cases.

       
specific Info package

be moved to new one.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 27 Sep 2009 14:14:52 +0200

Hi,

>Surprised to see you still working in Sunday. We work today because we switch one day for Chinese National Holiday:)

We work because SIP is our life - sadly, one could say :)

>Thanks for the guidance. This discussion is better to be directly to 3GPP or other SDOs. Let's continue the discussion on I-D itself. See inline response.

>>You mean you want to use Recv-Info in the INVITE request to tell the UAS it can send a special XML body back in the 200 OK?
>>
>>Timer modification function should be always available which means the UAC always support it. It does not require the UAC to indicate it supports using Recv-Info nor indicate it is willing to be changed.
> >
>
>Why would a UAC always support it? Not a single one of the UAs I currently have supports it.  It seems like a totally proprietary hack that only a few 3GPP-compliant UAs would support. Definitely the kind

First, an XML body in the 200 OK has absolutely NOTHING to do with the I-P mechanism. You don't use Recv-Info to indicate what you can receive in a 200 OK response - you use Recv-Info to indicate what you can receive in an INFO request, only an INFO request, and nothing but an INFO request.

Second, in your case, the UAC should indicate support of the XML body MIME using the Accept header. If it doesn't, and the UAS still sends the XML body in the 200 OK the UAS does not behave according to 3261. If 3GPP thinks that's ok, it's their choise. But, again, that has nothing to do with the I-P mechanism.

Thrid, for configuration and management, I would assume that indicating willingess to receive is "hard coded" into the user equipment by the operator and/or manufacturer, ie the user can not choose whehter he wants to receive conf/mgmnt Info Packages.

>I will wait to see the new version of the I-D before I post any new comments. For the time being, I understand what you mean. However I still think mixing the concepts between Capability Support and Willingness is not
>a good idea.

You can use OPTIONS to determine/indicate general capability support. A UA would normally indicate all Info Packages that it supports in the OPTIONS request/response. But, still, that doesn't mean that one is free to use them in a session - unless the UA explicitly indicate willingess to receive them for that session.

A new draft is on its way. We have taken a second look at it, to make sure things are clear. But, feedback is of course welcome.

But, the idea is still: if you want to receive something, you indicate it. If someone then sends something else, it is an error case (or, a race condition case). SDOs that want to be compliant with the mechanism shall not send Info Packages for which willingness have not been indicated.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 27 Sep 2009 14:15:32 +0200

Hi,

>size and fragmentation on responses delivered over UDP.
 
I agree.
 
In fact, I think 3GPP CT1 has a couple of ongoing use-cases where solution alternatives to return data in SIP responses have been presented. But, concern has been raised towards such solutions, due to the UDP reason indicated by Dean.

Regards,
 
Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 27 Sep 2009 23:48:33 +0200

See below. 

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Sunday, September 27, 2009 3:00 AM
> To: Linyi TIAN
> Cc: 'SIPCORE'
> Subject: Re: [sipcore] (Info event) Questions about 
> > In 3GPP solution if a SIP INVITE is sent from UAC, the UAS can send 
> > one XML document within SIP 200 OK to change the timer. We 
> think this 
> > is a simple mechanism. On the other hand this is a 
> configuration and 
> > administration task which does not need the UAC to indicate the 
> > willingness to be configured. It should be always available.
> 
> I have to say Huh? If I understand the approach, it's about 
> the strangest mechanism I can imagine. It's pretty much a 
> violation of every SIP extensibility principle every discussed.
> 
> pretty much completely forbidden) because we have no way to 
> manage size and fragmentation on responses delivered over UDP.
> 
Moreover you have no means of indicating that the body was received as there is no response to the response. Therefore essentially you are just using the SIP message body as a transport mechanism, without any of the external feature of SIP. Which leads to the question of why do you need to embed this in SIP in the first place.

> > If Recv-Info header can be decoupled with new SIP INFO, it 
> could be ok 
> > to use it for this function.
> 
> 
> You mean you want to use Recv-Info in the INVITE request to 
> tell the UAS it can send a special XML body back in the 200 OK?
> >
> > Timer modification function should be always available 
> which means the 
> > UAC always support it. It does not require the UAC to indicate it 
> > supports using Recv-Info nor indicate it is willing to be changed.
> >
> 
> Why would a UAC always support it? Not a single one of the 
> UAs I currently have supports it.  It seems like a totally 
> proprietary hack that only a few 3GPP-compliant UAs would 
> support. Definitely the kind of thing that requires feature 
> negotiation.
> 
This has so far not been anywhere near 3GPP.

> ...
> 
> >
> > In IETF, the current draft is really confusing about capability 
> > support and indicating willingness. Recv-Info header is used to 
> > indicate the support for SIP INFO framework. It is also used to 
> > indicate willingness. The error 469 was for that purpose as 
> well. We 
> > think two concepts are not the same and should be clearly described.
> 
> 469 is a dialog-terminating error condition. It's much better 
> to just not send the offending message because you know the 
> other end isn't capable and willing than it is to make your 
> dialog explode and die.
> 
Yes, given that the main purpose of SIP is to establish your dialog, and the INFO transfer requirements at best can be regarded as auxiliary. If your requirements put the precedence the other way round, why are you using SIP.

---

From: Linyi TIAN <[email-masked]>
Date: Mon, 28 Sep 2009 09:21:30 +0800

> 
> Thrid, for configuration and management, I would assume that indicating
willingess to
> receive is "hard coded" into the user equipment by the operator and/or
manufacturer, ie
> the user can not choose whehter he wants to receive conf/mgmnt Info
Packages.
[Linyi TIAN] Hard coded is one way. For this configuration feature, is SIP
INFO framework the best mechanism to be used? Is there any other
alternatives?

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 28 Sep 2009 09:03:55 +0200

You CAN NOT use the I-P mechanism to negotiate what you are going to send in a 200 OK response. 

As I said, in your case you should use the Accept header (eventhough sending stuff in the 200 response in general is not a good idea, as indicated by Dean).

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Linyi TIAN [mailto:[email-masked]]
Lähetetty: ma 28.9.2009 3:21
Vastaanottaja: Christer Holmberg; 'Dean Willis'
Kopio: 'SIPCORE'
Aihe: RE: [sipcore] (Info event) Questions about WillingnessandCapabilitynegotiation
 
willingess to
manufacturer, ie
Packages.

---

From: Linyi TIAN <[email-masked]>
Date: Mon, 28 Sep 2009 16:11:41 +0800

> 
> You CAN NOT use the I-P mechanism to negotiate what you are going to send
in a 200
> OK response.

[Linyi TIAN] I never said I will use I-P to do this.

I mean for this administration feature we may not use this I-D at all if

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 28 Sep 2009 11:01:29 +0200

Hi, 

>I mean for this administration feature we may not use this I-D at all
if Recv-Info is mandated. So please read my question again:

Your question was whether there are other alternatives for UA
configuration, right?

I think there are a number of other alternatives.

In fact, I have never heard about INFO being used for UA configuration.
INFOs can only be sent within a session, and that would mean that you
can't configure the UA unless it has established a session...

Or, are you talking about configuration which IS specific to the ongoing
session?

In any case, assuming you would use INFO, I still don't understand why
can't use Recv-Info. If the UA is going to implement support of the I-P,
why can't it implement support of the Recv-Info???

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Sep 2009 14:44:06 -0500

>> INFO framework the best mechanism to be used? Is there any other

I'm guessing from my weak understanding of the proposal that either  
the SIP configuration framework or session policy framework might be  
closer to meeting your goals than an INFO package would be.

See:

http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15

http://tools.ietf.org/html/draft-ietf-sip-session-policy-framework-06

Specifically, if you are talking about a timer that is valid only for  
the current INVITE-initiated session, then the session-associated  
policy part of the session-policy draft would be most likely to be  
fruitful.

If the timer is persistent across multiple sessions, then INFO would  
be completely wrong, and either the session-independent policy model  
of the session-policy draft might work, or the configuration framework.

Or you could do what IETF and 3GPP probably should have done all  
along, which is to develop a straightforward HTTP/XML configuration  
model for SIP devices.

--
Dean

---

From: Linyi TIAN <[email-masked]>
Date: Tue, 29 Sep 2009 08:37:18 +0800

> of the session-policy draft might work, or the configuration framework.

[Linyi] You finally clarified my doubt. This is the guidance I am seeking
for. The timer is to control the reporting frequency for watched content. So
mostly the timer is persistent across multiple sessions. 

That's why I was thinking willingness is not needed for this configuration
scenario and I believe there is an abuse for this I-D for this feature. What
I heard in other SDO is that SIP INFO Framework is the only mechanism (or
the correct one) to do this. 

I appreciate your effort to help clarify the alternatives.

Cheers,
Linyi

> Sent: Tuesday, September 29, 2009 3:44 AM
> To: Linyi TIAN
> WillingnessandCapabilitynegotiation
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 29 Sep 2009 09:03:26 +0200

Hi,

>I appreciate your effort to help clarify the alternatives.

I think there are two issues here:

The FIRST one is how you want to use Info Packages, by sending packages to clients who haven't indicated support of them. I hope we can agree that it will not be allowed in the I-P spec.

SECOND, you ask whether I-P is the most appropriate mechanism for your use-case in the first place. Based on the discussion so far, that does not seem to be the case. I guess you COULD use INFO, in which case the UA would have to insert Recv-Info, but I think you should look into other alternatives also.

Regards,

Christer