Re: [Sip] INFO issues: Backwards Compatibility and Forwards Detection

[Eric Burger <eburger at standardstrack.com>]

And again. See the bottom for the continuation.

On Aug 3, 2008, at 2:05 PM, Eric Burger wrote:

> The current text states that if a UA does not support receipt of any  
> Info Packages, it MUST drop the Info-Recv header.  Likewise, if the  
> UA does not support sending any Info Packages, as would be the case  
> if a UAS does not support any of the Info Packages offered by the  
> UAC, it MUST drop the Info-Send header.
>
> As an extreme example, if a UAS does not want to send any Info  
> Packages to a UAC and simultaneously the UAS does not support any of  
> the Info Packages offered by the UAC, the UAS will have neither an  
> Info-Send nor an Info-Recv header.  In this case, the UAC cannot  
> disambiguate between a legacy UAS and an Info Package-aware UAS that  
> simply does not want to receive INFO messages.
>
> Is this a problem?  On the one hand, one could argue a UAS that does  
> not support any INFO packages may still support proprietary INFO  
> packages or the legacy, standards track INFO usages.  On the other  
> hand, one could argue a UAS that supports INFO packages yet

states they do not want to participate in an INFO-based session should  
not get any INFO messages.

I would offer a clean standards-based way around this is to deliver  
Info Packages for ISUP and QSIG simultaneously with the INFO Package  
Framework.  That means that if anyone is going to implement Info  
Packages and they want to process ISUP and QSIG (SIP-T), they can do  
it out of the box. Backwards compatibility works because the endpoint  
would still have a manual configuration to talk SIP-T with the legacy  
device. It also means the endpoint can immediately talk Info Packages  
with Info Package-aware endpoints for SIP-T purposes, without fear of  
failure. Legacy devices will do what they always did, and the fact  
there is no Info-Recv or Info-Send header lets the Info Package-aware  
device know they are working with a legacy device. If there is an Info- 
Recv or Info-Send header, but the SIP-T package is not present, the  
Info Package-aware device will know at once the other device does not  
do SIP-T.  I would offer this is a more robust and rich interface, but  
it does come at the cost of "porting" the SIP-T legacy INFO uses into  
Info Packages.

I would volunteer to do the porting, if (1) people think this is a  
valuable exercise or (2) people value the robust interface.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip