Re: draft-johnston-sipping-cc-uui-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 
Keith, 

I agree with Alan. We also prefer a standards track document, with the proposed new header field and option tag, if it does not take years until we have a stable syntax so people can implement it. 

Regards
Laura







-----Ursprüngliche Nachricht-----
Von: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Sonntag, 23. November 2008 21:28
An: Henry Sinnreich; Joanne McMillen; Paul Kyzivat; Cullen Jennings; Laura Liess
Cc: sipping; Hülsemann, Martin
Betreff: Re:  draft-johnston-sipping-cc-uui-05

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.

Do others share Henry's view, or should this document ultimately proceed in SIP as a standards track document, with the proposed new header field and option tag.

regards

Keith 

> -----Original Message-----
> From: Henry Sinnreich [mailto:hsinnrei@xxxxxxxxx] 
> Sent: Friday, November 21, 2008 2:45 PM
> To: DRAGE, Keith (Keith); Joanne McMillen; Paul Kyzivat; 
> Cullen Jennings; Laura Liess
> Cc: sipping; Huelsemann,Martin
> Subject: Re:  draft-johnston-sipping-cc-uui-05
> 
> Keith,
> 
> >what protocols other than those carried by ISDN did you want to map 
> >over SIP.
> 
> This is a good question and allows me to clarify two points:
> 
> 
>  *   Since the I-D <draft-johnston-sipping-cc-uui>  is 
> solving a real problem for some people, it should be 
> published as an informational RFC ASAP. Far too much design 
> by committee has already been perpetrated :-)
> 
> 
>  *   As for what other protocols to map over SIP, please 
> recall our I-D on "simple SIP": The option to use SIP only 
> for rendezvous and session setup negotiation. Simple SIP 
> solves we believes this (send data along with a call 
> transfer) and other requirements as well over IP networks and 
> over the Internet.
> 
> Henry
> 
> 
> On 11/20/08 9:27 PM, "DRAGE, Keith (Keith)" 
> <drage@xxxxxxxxxxxxxxxxxx> wrote:
> 
> So to Henry - what protocols other than those carried by ISDN 
> did you want to map over SIP.
> 
> I would argue that in an entirely SIP environment, this would 
> be either using SIP as a transport protocol, and therefore 
> incorrect, or that the mechanisms already exist in such an 
> environment for carry things like MESSAGE which solve this problem.
> 
> The ISDN issue is that this transport is already embedded in 
> a call control message, and therefore by splitting it out, 
> you would lose the coupling semantic that exists in the ISDN 
> protocol. Therefore ISDN has an interworking case where there 
> is a need to do this.
> 
> Does the interworking with any other protocol generate such a 
> need where we could see the need to extend the current requirements.
> 
> regards
> 
> Keith
> 
> > -----Original Message-----
> > From: sipping-bounces@xxxxxxxx
> > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Henry Sinnreich
> > Sent: Thursday, November 20, 2008 9:21 PM
> > To: Joanne McMillen; Paul Kyzivat; Cullen Jennings; Laura Liess
> > Cc: sipping; DRAGE, Keith (Keith); Huelsemann,Martin
> > Subject: Re:  draft-johnston-sipping-cc-uui-05
> >
> > Joanne,
> >
> > >Can we eliminate the "futures" discussion here for that
> > "other track" and just deal with the immediate need please?
> >
> > This is new to me: IP networks (such as inside contact centers, 
> > enterprises) and the Internet are futures? :-)
> >
> > But I do not intend to press this any further.
> >
> > Henry
> >
> >
> > On 11/20/08 1:17 PM, "Joanne McMillen" <joanne@xxxxxxxxx> wrote:
> >
> > I can tell you what one author thinks Henry. ;-)
> >
> > Like Laura and others have stated - we have an immediate need here.
> >
> > Where this may go in the future with enhanced definitions 
> in SIP is  
> > future consideration.
> >
> > We all agree (I suspect) that SIP can be far more robust 
> here for this 
> > "functionality".
> > When and if someone wants to define what that new and robust 
> > "functionality" is in SIP it would beg the question as to 
> whether or 
> > not this specific header for UUI is the right avenue for that.
> > It could be and it couldn't be - I can see that debate going either 
> > way and for very good reasons for going either way.
> > The bottom line is we have an immediate need right now that 
> this draft 
> > addresses - I do not want to see this get bogged down by future 
> > concerns - and the definition allows for that if anyone chooses to 
> > extend it going forward in SIP...
> >
> > Can we eliminate the "futures" discussion here for that 
> "other track" 
> > and just deal with the immediate need please?
> >
> > Thanks,
> > Joanne
> >
> >
> > ----- Original Message -----
> >
> > From:  Henry  Sinnreich <mailto:hsinnrei@xxxxxxxxx>
> >
> > To: Laura Liess <mailto:Laura.Liess@xxxxxx>  ; Cullen Jennings 
> > <mailto:fluffy@xxxxxxxxx>  ; Paul Kyzivat 
> <mailto:pkyzivat@xxxxxxxxx>
> >
> > Cc: sipping <mailto:sipping@xxxxxxxx>  ; Joanne McMillen 
> > <mailto:joanne@xxxxxxxxx>  ; DRAGE,  Keith (Keith) 
> > <mailto:drage@xxxxxxxxxxxxxxxxxx>  ; Huelsemann, Martin 
> > <mailto:Martin.Huelsemann@xxxxxxxxxx>
> >
> > Sent: Thursday, November 20, 2008 11:37  AM
> >
> > Subject: Re:   draft-johnston-sipping-cc-uui-05
> >
> >
> > >  1) Get this syntax agreed as soon as possible  because it
> > is needed
> > > by the industry in the today's PSTN/SIP mixed  environment.
> >
> > Well, I have here to make the observation that SIP-PSTN is not the 
> > only mixed environment.
> > SIP is also used on IP networks and on the  Internet and 
> the UUI may 
> > look there vastly more different - probably extensible and very 
> > powerful. And it may be just as urgent.
> >
> > So it  appears the SIP UUI may end up with two tracks, one for 
> > compatibility with  ISDN and the other for the IP networks and the 
> > Internet.
> >
> > What do the  authors think?
> >
> > Henry
> >
> >
> > On 11/20/08 9:03 AM, "Laura Liess"  <Laura.Liess@xxxxxx>  wrote:
> >
> >
> >
> > > 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?
> >
> > Paul,
> > I do not see why  we should not do both and leave the 
> decision to the 
> > market.
> > IETF did this  in the past.
> >
> >     1) Get this syntax agreed as soon as  possible because it is 
> > needed by the industry in the today's PSTN/SIP mixed 
> environment. If 
> > we do not come up very soon with a standard, people will  use 
> > proprietary extenssions. I think we should avoid this. 
> There are no  
> > technical reasons not to move on with the draft.
> >
> >      2) In the long term we could develop a "native sip"
> > syntax which is  more flexible, easier to implement, 
> whatever.... It 
> > will have advantages in  a "sip native"
> > environment and it will be adopted when the "native  sip"
> > environement is in place.
> >
> > Laura
> >
> >
> > >
> > > Once  its done it will not make sense to develop a 
> different syntax 
> > > for  native sip use.
> > >
> > > 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.
> > >
> > > Thanks,
> > >  Paul
> > >
> > >>> Until we solve this with an appropriate  mechanism, SIP 
> will not 
> > >>> make headway into areas such as  contact centers.
> > >>>
> > >>> And, there is a limit on the  size of data - please read
> > the draft.
> > >>>
> > >>
> > >>  Hmm - you are right that when I read it, I had missed the
> > key part
> > >> of
> > >>
> > >>    Note that ISDN limits UUI to 128  octets in length.
> > While this header
> > >>    field  has no such limitations, transporting UUI longer
> > than  128
> > >>    octets will result in interoperability  failures when
> > interworking
> > >>    with  ISDN.
> > >>
> > >>>
> > >>>
> > >>> And the  draft says nothing about proxy inspection and
> > routing.  I
> > >>> mentioned it in my email because we know that clever
> > implementors
> > >>> will do clever things.
> > >>>
> > >>> The  draft is not making the arguments you specify.
> > >>>
> > >>>  So, if I remove the text in your comments about this
> > being an  ISDN
> > >>> parameter mapping issue, the size being unlimited, and
> > problematic
> > >>> proxy behavior, I don't think there are any  remaining issues.
> > >>>
> > >>> If you have issues with the  requirements in the draft,
> > let us know
> > >>> so we can clarify  them.
> > >>>
> > >> I can easily imagine cases where customer  sensitize
> > information was
> > >> transfered over this and it was going to  an remote agent
> > phone that
> > >> went through another trust domain to  route the call to
> > the agent. In
> > >> these cases, I think an important  requirement would be to
> >  protect
> > >> the draft from authorized  access by intermediaries.
> > >>
> > >>>
> > >>
> > >>  Cullen in my individual contributor role
> > >>
> > >>  _______________________________________________
> > >> 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
> >
> 
> 
_______________________________________________
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


[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux