Can I just note that this is not really an ISDN parameter. The ISDN parameter is an envelope and information passed into SIP is the contents of the envelope, which can be any of a number of different protocols as indicated by the protocol discriminator. I do agree that the main justification for its existence is to allow interworking with the legacy ISDN usages of the same parameter. regards Keith > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Cullen Jennings > Sent: Saturday, November 15, 2008 10:03 PM > To: Joanne McMillen; Alan Johnston > Cc: sipping > Subject: draft-johnston-sipping-cc-uui-05 > > > So I'm just trying to help this move forward in a expedient > way that solves the need of the people that want it. I will > no doubt regret sending this message because this is not a > draft I plan to spend a lot of time on - however, I would > rather see the draft find a way to quickly address and move > past objects that I view as likely to come up about it sooner > or later. In the past we have had some ideas that went round > and round the WG for a long time with little progress. Some > of these had a characteristic argument that went a bit like: > > It's meant to be from UA that understand it to UA that > understand it, which would be tunneling, but it's not > tunneling because proxies might read it too, and if they > understand it, they route the call differently than if they > did not understand it, but proxies are not required to > understand it, unless of course you want your call to be > routed correctly so you have to support it. And the content > of the data being transmitted is not specified and we can't > say what any device would do with it or how that would be implemented. > > I hope this draft is not making an argument remotely close to > that because if it is, I predict it will be in the WG for a long time. > > Right now, when I remove the text about the motivation for > the draft, the normative behavior I get left with is a new > header that carries unspecified but important binary data in > requests and responses (with no limit on data size) and and > an option tag which may or may no be used. I can not imagine > any way where two vendors could take that level of > specification and build interoperable equipment. > > A separate topic that is tangentially related to this draft > is we have also seen a steady stream of just one more ISDN > parameter in yet another unstructured way. All the parameters > in ISDN are useful for someone for something - if we are > going to be adding them to sip headers or tel URI parameters, > I'd rather have some way of deciding which ones we add and > which one we don't instead of doing each one one at a time. > I'm not arguing you should use NSS, but I do wish we had some > sort of "test" that we could apply to decide what sort of > ISDN parameters we want to include and which ones are better > deal with some other way. > > Cullen in my individual contributor role. > > On Nov 12, 2008, at 6:35 PM, Joanne McMillen wrote: > > > in line... > > ----- Original Message ----- > > From: Cullen Jennings > > To: Alan Johnston > > Cc: sipping ; Joanne McMillen > > Sent: Wednesday, November 12, 2008 4:06 PM > > Subject: Re: [Fwd: New Version Notification for draft- > > johnston-sipping-cc-uui-05] > > > > > > I just started actually thinking about this draft and it made me > > wonder about the requirements. > > > > Is the need here to tunnel the ISDN UUIE from UAC to UAS or is it a > > requirement that all the SIP routing elements need to > understand the > > UUIE? Without understand what part of the network is required to > > support this, makes it sort of hard to decide what is the > best way to > > do this. > > > > [Joanne] Why is this an either or? This is not about "tunneling". > > Nor is it about > > all routing elements needing to understand it. Routing > elements that > > do not understand it at all and work accordingly for any > SIP headers > > they do not understand/support simply pass the headers on. > It's about > > any element that chooses to understand the content and act upon it. > > And that is up to an agreement between elements because the actual > > content of it needs to be agreed upon between them as it > will signal > > only what they agreed to - it does not have any standard > content that > > just any entity could translate. Even in ISDN it was something that > > went blindly through PSTNs, but that could be acted upon by > any "user" > > entity. Gee, does that sound like a B2BUA in SIP or what? Does IETF > > still take the stance in SIP that a B2BUA is "your own > devil to deal > > with"? ;-) If we can just get the header defined then there is the > > same mechanism in SIP that intermediate B2BUAs could indeed > choose to > > play with in SIP - or not - their choice - just like "user > end PBXs" > > in ISDN... > > There are many interested parties in what we can do with > this in SIP > > while full well understanding that ultimately if we have to get the > > information through a SP with an > > SS7 backbone then this > > is how it needs to be done. > > > > > > I was also wondering if Q.1980.1 NSS pretty much solved > this problem > > or if something more was needed. > > [Joanne] Oh come on Cullen - we both know the answer to > that. Yes - if > > you want a tunneling solution. > > Most folks I have talked to about NSS have two responses - an > > irritated sigh with eyeball roll is the nice one. > > Doing this via NSS is like using a tank to kill a snail. This is > > exactly why we have this draft... > > > > Cullen <with my individual contributor hat on> > > > > > > On Oct 31, 2008, at 13:17 , Alan Johnston wrote: > > > > > We have revised the UUI draft based on comments in Dublin. > > > > > > The major changes are: > > > > > > 1. Added 7 requirements for the mechanism. > > > 2. Removed some controversial proxy use cases. > > > > > > Comments are most welcome. > > > > > > Thanks, > > > Alan > > > > > > -------- Original Message -------- > > > Subject: New Version Notification for draft-johnston-sipping-cc- > > > uui-05 > > > Date: Fri, 31 Oct 2008 13:13:58 -0700 (PDT) > > > From: IETF I-D Submission Tool <idsubmission@xxxxxxxx> > > > To: alan@xxxxxxxxxxxxxx > > > CC: joanne@xxxxxxxxx > > > > > > > > > > > > A new version of I-D, > draft-johnston-sipping-cc-uui-05.txt has been > > > successfuly submitted by Alan Johnston and posted to the IETF > > > repository. > > > > > > Filename: draft-johnston-sipping-cc-uui > > > Revision: 05 > > > Title: Transporting User to User Call Control Information > in SIP for > > > ISDN Interworking > > > Creation_date: 2008-10-31 > > > WG ID: Independent Submission > > > Number_of_pages: 16 > > > > > > Abstract: > > > Several approaches to transporting the ITU-T Q.931 User to User > > > Information Element (UU IE) data in SIP have been proposed. As > > > networks move to SIP it is important that applications requiring > > this > > > data can continue to function in SIP networks as well as > the ability > > > to interwork the information to/from ISDN for end-to-end > > > transparency. This extension will also be used for native SIP > > > endpoints implementing similar services and interworking > with ISDN > > > services. This document discusses requirements and > approaches and > > > recommends a new header field User-to-User be > standardized. Example > > > use cases include an exchange between two User Agents, retargeting > > by > > > a proxy, and redirection. An example application is in > an Automatic > > > Call Distributor (ACD) in a contact center. > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > 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
