I'd like to support this draft moving ahead for standardization. Our company has done an implementation of an earlier version of the draft in a media gateway and the feature has been very popular among customers. The primary use case has been for collecting user information transported over the ISDN network and bringing it into a SIP-based call center using the proposed SIP header. However, there are other use cases being considered, all of which build on the existing ISDN UUE supplementary service. We have not had any interoperability issues. If the implementers understand how the UUI data is being used for the ISDN service, decoding it for use in the SIP environment has not posed a problem. We also support facilities such as SIP-T in our gateways which can support ISUP / ISDN content as MIME attachments, but most SIP implementers do not support these MIME extensions, so the UUI header is a valuable addition. I have a couple of responses on comments below from Paul(see JR). James -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Paul Kyzivat Sent: Wednesday, November 19, 2008 7:57 PM To: Cullen Jennings Cc: DRAGE, Keith (Keith); Joanne McMillen; sipping Subject: Re: draft-johnston-sipping-cc-uui-05 Cullen Jennings wrote: > > On Nov 17, 2008, at 10:22 , Alan Johnston wrote: > >> Cullen, >> >> Keith is correct - this is not about mapping ISDN parameters into SIP, >> it is about mapping a very successful and popular ISDN *service* into >> SIP. >> > Fair enough - I agree with you and Keith on this. This is precisely my concern. By doing this we are adopting this syntax for carrying data for what will eventually be *SIP* services. Is this *really* the way we want to support those services in a native sip environment? JR - This draft is not about creating a new SIP service, but rather interoperating with the existing UUE service in ISDN. Once its done it will not make sense to develop a different syntax for native sip use. JR - Why not? If the service is valuable in gateways, it may also be valuable in the pure SIP environment, but a new service would not need to be backward compatible with ISDN syntax. If we go this way, every sip entity that needs to deal with these will need to have the needed ASN.1 encoding/decoding logic. I don't know if that is trivial to special case because I don't know what all the various formats are. But it would at least be annoying. JR - Since the draft's focus is on interoperating with ISDN, the binary format is defined in Q.931 and an implementer that wants to decode it will have such a facility. The actual semantics of the data depend upon the use case. Thanks, Paul _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
