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

RE: [Sip] B2BUA & Max-Forwards



This thread is definitely going way beyond what it should do (both in scope and duration) - it did however start (about a 100 messages ago) with some reasonable modifications to the B2BUA definition, and save those relatively minor modifications, I do not want to see any other modifications in RFC 3261 or its next revision.

I certainly will not agree to removal of any existing definition of B2BUA.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
> Sent: 06 December 2002 15:40
> To: 'Jonathan Rosenberg'; Pete Cordell
> Cc: David R. Oran; Dean Willis; sip@ietf.org
> Subject: RE: [Sip] B2BUA & Max-Forwards
> 
> 
> 
> I agree with Jonathan.  As mentioned earlier this week 
> apparently, there is
> already work underway by some individuals to write an 
> informational draft
> documenting BBUA scenarios/call flows. 
> 
> I'll keep my fingers crossed that the existence of such a 
> document can save
> us from another round of B2BUA discussions again in 3 months. 
> 
> Regards,
> Mary.
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, December 06, 2002 12:59 AM
> To: Pete Cordell
> Cc: David R. Oran; Dean Willis; sip@ietf.org
> Subject: Re: [Sip] B2BUA & Max-Forwards
> 
> 
> 
> 
> Pete Cordell wrote:
> > Dave,
> > 
> > To save your disagreeableness, can we say something like:
> > 
> > "A B2BUA MUST perform loop prevention.  One way to do this 
> is to propagate
> > the Max-Forwards header from the incoming request to the 
> outgoing request
> in
> > the same way that a proxy does."
> 
> A statement like this is completely out of scope for rfc3261. 
> It might 
> be a reasonable statement to make in some kind of application 
> document 
> that describes a particular type of b2bua. However, it makes no more 
> sense to say this in RFC 3261 as it would be to discuss the ways in 
> which to build a focus or a 3pcc controller (both of which are also 
> informational, by the way).
> 
> I can't resist pointing out that much of this is deja vu. Folks may 
> recall heated discussions in Adelaide, where there was a bof 
> (I think) 
> that wanted to have a working group to specify SIP to H.323 
> conversion. 
> THe same arguemtns that were made there are being made here; its an 
> application level issue, there are many ways to do it, don't stifle 
> creativity, etc. In fact I recall that Dave was, as always, quite 
> vociferous on these points.
> 
> The eventual conclusion in the h323/sip conversion case was 
> to write an 
> INFORMATIONAL RFC that documents reasonable practices in 
> building such a 
> device. I believe the same logic and conclusions apply here. If folks 
> have a particular type of b2bua application they are fond of, please 
> feel free to write up your implementation advice and I am 
> sure sipping 
> would consider whether or not it would make a useful 
> informational RFC.
> 
> However, it is completely inappropriate to ever make such application 
> logic normative, and even more inappropraite for such wording 
> to be in 
> rfc3261.
> 
> Anyway, I too am tired of this thread. I think, in fact, there is 
> "rough" consensus to remove the definition of b2bua entirely from 
> rfc3261 in its next revision (which is quite some time in the future 
> anyway). However, I'll let the chairs decide that.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip