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

From: Eric Burger <[email-masked]>
Date: Sun, 3 Aug 2008 14:05:43 -0400

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 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Sun, 3 Aug 2008 15:16:54 -0400

And again. See the bottom for the continuation.

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

> 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.
>

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip