I just relooked at the ISDN documents, and it is only user-to-user service 1 explicit requests that carry the required as opposed to preferred indicator. My understanding was that we were only interworking with user-to-user service 1 implicit and therefore the option tag would not be required for this. Note that the the required versus preferred information in DSS1 and QSIG is carried in the Facility information element and not in the DSS1/QSIG User-user information element. In ISUP it is carried in the the user-to-user indicators parameter with service 1 indicated as "requested, essential" and the data itself is in the user-to-user information parameter. Currently I know of no interworking specification attempting to use the proposed User-to-User header field that additionally maps the user-to-user indicators parameter from ISUP. regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxx] > Sent: Monday, November 24, 2008 4:54 PM > To: DRAGE, Keith (Keith) > Cc: Henry Sinnreich; Joanne McMillen; Cullen Jennings; Laura > Liess; sipping; Huelsemann,Martin > Subject: Re: draft-johnston-sipping-cc-uui-05 > > > > DRAGE, Keith (Keith) wrote: > > To publish as informational under the current IANA > registration procedures would mean that the solution would > need to be downgraded to a P-header, and the option tag would > need to be removed. > > The option tag is there to meet one of the ISDN > interworking requirements, as it is possible to say in DSS1 > that the call should only proceed in the UUI is understood - > i.e. interworking capability will be lost. > > Is the requirement that the call should only proceed if the > overall UUI transport mechanism is understood? Or only if the > particular UUI type is understood? (I got the impression from > earlier discussion in this thread that each of those types > has an independent usage.) > > If its important that the particular type be understood, then > one option tag doesn't seem sufficient to get the desired effect. > > 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
