Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

[Christer Holmberg <[e-mail]>]

Hi, 

>>>Another hurdle you're going to face is harmonizing your 
>>>proposal with RFC 5897. All three of your examples rely on doing, just about as 
>>>vigorously as possible, precisely what RFC 5897 says not to do.
>>
>>Feature tags indicate support of a capability. EVERY 
>>feature tag does that - even if inserted in a Contact header 
>>field by a UA - and the feature tag specification needs to 
>>define the meaning of that capability.
>>
>>The important thing is that it cannot be assumed that other 
>>entities understand the meaning of the feature tag in order 
>>to progress a call (in such cases you will also need an 
>>option-tag, inserted in a Require/Proxy-Require header field).
>> 
>>There was also an extended discussion (battle?), around the 
>>time the callerprefs came out, about the validity of using 
>>feature-tags (capabilities) to identify arbitrary *services* where the 
>>service was to be defined in some external, potentially 
>>restricted document.

3GPP specifications are as external as IETF RFCs.

It is also important to remember that the proposed work is not about specifying specific feature tags, but a generic mechanism to carry proxy-inserted feature tags. 

I have no problem to include a statement saying that feature tags specifications that use the mechanism MUST be publicly available.

>The crux of the argument was whether capabilities were 
>orthogonal to one another or not. The concern was (and 
>remains) that interoperability is severely limited if there 
>are potentially many ways of specifying the same capability, 
>as part of this service or that service.

Yes, but that relates to most things we do.

>(IIRC, one of the examples used was video calling, where 
>somebody might describe a capability "video-phone" that 
>implies a particular combination of audio and video. Two UAs 
>that supported this might work well together, but somebody 
>with a UA that supports exactly the same media types and 
>*could* interoperate if connected, might fail to interoperate 
>for lack of specifying the proper feature-tag.)
> 
>We run a risk of going through the same thing here. That is 
>what 5897 was about too.

The procedures associated with the 3GPP feature tags are very well documented, rather than being something general as "audio" and "video".

And, take sip.instance as an example. It is useless unless entities support procedures associated with it. But, if UA_A inserts sip.instance, and UE_B does not support it, they will still be able to communicate. But, if they want to use features associated with the feature tag, they need to support the procedures defined for that feature. There is nothing in the "SIP signalling" that tells the entities what to do, if the sip.instance e.g. is going to be used outside the dialog (e.g in a REFER request).

Regards,

Christer







> 
> 	Thanks,
> 	Paul
>