Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2012 09:57:46 +0200

Hi Paul,

Some thinking on the contact issue.

>>>> Section 5.3.3 says:
>>>>
>>>>      If a SIP feature cap is inserted in a Feature-Caps header field of a
>>>>      SIP REGISTER request, or within a response of such request, it
>>>>      indicates to the receivers of the request (or response) that the
>>>>      feature associated with the SIP feature cap is supported for the
>>>>      duration of the registration, and for all SIP transactions associated
>>>>      with the registration, until the registration is re-freshed or
>>>>      terminated.
>>>>
>>>> There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases?
>>>>
>>>> - if there are no contacts in the register, are feature-caps irrelevant?
>>>> - if there is more than one contact in the register, do the feature-caps
>>>>     apply to all of them?
>>>>
>>>> Then the response should contain all the registered contacts, not 
>>>> just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those contacts expire? Or should the requester assume they only apply until *its* contacts expire?
>>>>
>>>>      Unless a SIP feature cap is inserted in a Feature-Caps header field
>>>>      or a re-registration, or within a response of such request, it
>>>>      indicates to the receivers of the request (or response) that the
>>>>      feature is no long supported for the registration.
>>>>
>>>> Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact?
>>>
>>> It's up to the entities that previously inserted the feature-caps to decide whether they will continue to indicate support when they receive a re-registration request/response - no matter whether it's a poll, addition of contacts etc.
>>>
>>> Personally I see no reason why they should *not* insert the same feature-caps in a pure poll request/response, but we should allow for cases where the feature is no longer supported when the poll request/response is received.
>>
>> I think you missed my point. Its really the same point as my question 
>> of what it means to put feature caps into a polling register.
>>
>> Since you want the registrar to consider the received feature caps to 
>> be stateful for the duration of the register, I want to know what 
>> that state is attached to. ISTM that it must be attached to 
>> particular contacts. Then, a polling register would presumably not 
>> update the state of any registered contact since it doesn't update any of them.
>>
>> On the flip side of that, if the registrar returns feature caps, what 
>> does the recipient attach that state to? The only thing it could 
>> attach it to that has a lifetime is the registration of a particular 
>> contact, since the registered contacts can expire independently.
>
> Ok, I think I understand. I need to think a little about it.

My suggestion would be:

- When outbound is *not* used, if support of feature F9 is indicated when contact C1 is registered, the feature is supported until C1 expires, is explicitly removed, or explicitly refreshed.

- When outbound *is* used, the same as above applies, but only for the specific C1 registration flow for which support of F9 has been indicated.

	Example: If I register C1, using two outbound flows (O1 and O2), and support of F9 is indicated for O1, when O1 is expired/removed/refreshed F9 is no longer supported.

- Whenever a contact is explicitly refreshed, entities MUST insert Feature-Caps if they still want to indicate support of the feature.

- For pure poll messages, where the REGISTER request does *not* contain a contact, my suggestion is that we say that the document does not define any semantics for usage of Feature-Caps in such requests/responses. If no semantics is defined, poll messages will not have any impact on previously indicated support of features, and entities MUST NOT insert a Feature-Caps header field in such requests, or their associated responses.

How does that sound? :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Apr 2012 10:37:54 -0400

Christer,

I *think* this sounds right.

But I'm not certain in the case of outbound. It seems like it might 
depend on the particulars of the feature. I say this because features 
are still so fuzzy. In some cases it might be that the behavior of the 
feature is coupled to the flow. In others it might not. Perhaps if I 
understood proxy-features better I wouldn't have that doubt.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2012 18:31:26 +0200

Hi,

> understood proxy-features better I wouldn't have that doubt.

I don't think that a feature, explicitly indicated for flow O1, can be implicitly applied also for O2. The support has to be explicitly indicated on each flow for which it applies.

Because, O2 may not even traverse the entity which indicates the support of the feature for O1, which means that when O2 is refreshed there will be no support indication - which would mean that the feature is no longer supported (at least not until O1 is refreshed, and the indication might be added again...).

(Probably that could be fixed, e.g. by saying that only the flow where support has been indicated can later refresh/remove that support. But, I think that would be too messy, e.g. if that flow expires etc.)

So, my suggestion would be that the support is indicated per flow. That's how it works in the 3GPP, where support is sometimes indicated based on the type of access network associated with a flow.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Apr 2012 12:46:35 -0400

OK.

	Thanks,
	Paul