Subject: RE: [Sip] B2BUA & Max-Forwards

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 9 Dec 2002 15:41:47 -0000

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: [email-masked] 

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]]
> Sent: 06 December 2002 15:40
> To: 'Jonathan Rosenberg'; Pete Cordell
> Cc: David R. Oran; Dean Willis; [email-masked]
> 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:[email-masked]]
> Sent: Friday, December 06, 2002 12:59 AM
> To: Pete Cordell
> Cc: David R. Oran; Dean Willis; [email-masked]
> 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
> [email-masked]                     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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Dec 2002 13:33:33 -0500

Drage, Keith (Keith) wrote:
 > 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.
 >

Well, we have some time to conclude this (since we are not revving 
rfc3261 for some time), but it was my sense that there was ROUGH 
consensus to remove it.

Rough doesn't mean unanimous of course...

-Jonathan R.

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 12 Dec 2002 11:23:10 -0800

I can't really see how it matters if the term B2BUA is defined in 3261bis or
not since it would make no normative changes to the specification either
way.

It does seem very obvious to me that B2BUA is a useful description of a
certain class of valid SIP applications. I'm sure the term will continue to
be widely used and one the most commonly occurring works in the sip mailing
lists. I can't imagine how we could wish the term away or even why we would
want too. Deans 10 rules of transparency will no doubt be used to describe
the characteristics of certain B2BUA. Thanks Dean.

So out of this long and dreary thread, I see only a few real proposals of

Do a INFORMATIONAL draft(s) with one or more of the following:

1) describing various transparencies of B2BUA
2) attempt some level of definition of what we mean by a B2BUA
3) show some call flows (like the service examples) that show possible call
flows for solving some of the common problems people are trying to solve
with B2BUA

My view is I don't see any particular harm in doing any of the above but I
would not have much time to help on them because I think there are more
important things. If other people do have time (as several have suggested
they do) lets say thanks and get on with it.

Cullen

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Drage,
> Keith (Keith)
> Sent: Monday, December 09, 2002 7:42 AM
> To: Mary Barnes; 'Jonathan Rosenberg'; Pete Cordell
> 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.
>