Re: INFO Framework: Tags

On Nov 24, 2008, at 10:33 AM, Bob Penfield wrote:

> The thing that makes me most uncomfortable with an option tag for  
> info-packages is that it is expanding the scope of an option tag  
> from a single well-defined extension/feature to a whole class of  
> features that are not necessarily related. I see it as being  
> analogous to defining an option tag for event-packages that could be  
> used to fail calls because the UAS does not support SUBSCRIBE/NOTIFY.

We have one; SUBSCRIBE. If it doesn't show in the Supported methods,  
don't send a SUBSCRIBE.

Unfortunately, INFO method support is not enough, as there are  
prepackage INFO implementations in the wild. So we have three cases to  
differentiate: No INFO, Old INFO, and new INFO packages.

> The other thing that is bothersome is that one day, the calls are  
> failing for your mystery application, the next day they succeed  
> because the UAS was upgraded to support SOME info-package, but not  
> your mystery feature and you will have to terminate successful calls  
> because of it.

But now you can look at the info package negotiation and figure out  
that it does not support the mystery-package, and tell what other  
packages it does support (and write the application to adapt to the  
available packages).
>
> I think we should change the section about OPTIONS to require the  
> UAS to include its supported info-packages in the response if the  
> request had a Recv-Info header. That way you could probe the far end  
> if you really require your info-package to be there.

While that makes perfect sense, it is inconsistent with the use of  
OPTIONS tags in RFC 3261. I'd like to change that part of 3261  
someday . . .

--
Dean

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