Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Sep 2003 10:56:55 -0400

I understand why you claim such a system is a B2BUA.
Of course, with that example, there are no rules whatsoever
on a B2BUA, except that each side is a UA.

Does that imply that there should not be any mention
of B2BUAs at all in any document other than 3261, which
is quite deliberately vague?

I would AT LEAST want to point out issues, such as 
the "one side fails, the other side should be brought down".
By your reckoning, would that be out of scope for a standards
track document, and merely notes in some BCP?

I've been seeing lots of B2BUA "misuse" lately.  The common
one is "I have a proxy that modifies headers, therefore
I call it a B2BUA, and everyone is fine".  There are
no protocol police, and there are no "architecture" police,
but I think it is in the community's interest to at least
provide expert guidance on how B2BUAs 'should' work.
This is an example.  'Should' is okay with me; it would let
your example be "legal".

Brian

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 10:43 AM
> To: 'Rosen, Brian'; [email-masked]'; Jonathan Rosenberg
> Cc: sip-ietf (E-mail)
> Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy
> restr ictions on all the b2bua's
> 
> 
> I think the major point is that, with B2BUAs, all bets are off.
> As long as they look like SIP UAs on both sides, they meet
> spec. There's nothing we can do about this. Cullen points
> out exactly what I was going to. I'll expand on this some.
> 
> I have a SIP phone on my desk. So does Alan. However,
> because I'm lazy, I often pick up my SIP phone and call
> his normal PSTN number. That goes to my PSTN gateway,
> through the PSTN to Alan's gateway, and rings Alan's
> SIP phone.
> 
> From a protocol perspective, my PSTN gateway, the PSTN,
> and Alan's PSTN gateway, as an aggregate, form a B2BUA.
> 
> Is there any reasonable way you can impose a restriction
> on such a system as a whole? No. As long as each SIP User
> Agent acts as a proper User Agent, everything else is
> completely dependant on the purpose of the system.
> 
> /a
> 
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Friday, September 05, 2003 9:06
> > To: [email-masked]'; [email-masked]
> > Cc: sip-ietf (E-mail)
> > Subject: RE: [Sip] sip-session-timer-11: why explicitly impose proxy
> > restr ictions on all the b2bua's
> > 
> > 
> > I thought it was because the two sessions the B2BUA bridges ought
> > to be considered one session wrt the session timer.  If one side
> > dies, the other one needs to be cleaned up.
> > 
> > That being said, if one side can support session timer, and the
> > other can't, the B2BUA could, if it was smart enough, maintain
> > the session timer on the one side, and clean up the other side
> > on failure.  It couldn't detect failure of the non-session-timer
> > side of course.
> > 
> > I was about to release -12, with only minor updates.  I guess
> > I'll let this thread play out before I release it.  I could
> > soften the text pretty easily.
> > 
> > I personally liked the fact that B2BUA behavior was discussed.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Brett Tate [mailto:[email-masked]]
> > > Sent: Thursday, September 04, 2003 3:49 PM
> > > To: [email-masked]
> > > Cc: sip-ietf (E-mail)
> > > Subject: [Sip] sip-session-timer-11: why explicitly impose proxy
> > > restrictions on all the b2bua's
> > > 
> > > 
> > > Why does draft-ietf-sip-session-timer-11 
> > > explicitly impose proxy related restrictions 
> > > on all the B2BUA's?
> > > 
> > > I agree that some of the proxy concepts are 
> > > good recommendations for some types of B2BUA's; 
> > > however they definitely do not apply to all 
> > > types of B2BUA's.  
> > > 
> > > And in general, I am surprised to see
> > > any draft explicitly requiring a B2BUA to act 
> > > like a proxy.  Some B2BUA's act completely like
> > > a UA; others act mostly like a proxy; and others
> > > act at various degrees between a proxy and UA.
> > > 
> > > 
> > > _______________________________________________
> > > 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
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 05 Sep 2003 12:27:21 -0500

>on a B2BUA, except that each side is a UA.
Congratulations, you've perfectly restated the definition of B2BUA,

>is quite deliberately vague?
In general, a B2BUA is a  UA, and is bound by all the requirements of a 
UA. I suggest that mentioning B2BUAs in IETF documents is only 
appropriate in a document specific to B2BUA behaviors, such as the 
proposed informational on how to build a B2BUA that works as much like a 
proxy as possible.

>track document, and merely notes in some BCP?
Is that actually the correct behavior for a B2BUA? What is the function 
of the B2BUA we're talking about? How do you know?

For example, the Asterisk conference bridge is a B2BUA that has the 
behavior of  bridging the audio between multiple external UAs. If one 
party on a conference expires, does that mean that the whole conference 
needs to be torn down?

>This is an example.  'Should' is okay with me; it would let
Again, you're thinking of the "mostly transparent b2bua that sort of 
works like a proxy, kindof, maybe, sometimes". This is probably a 
worthwhile topic for discussion, but shouldn't impact mainstream 
specifications in any way.

--
Dean

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 05 Sep 2003 13:48:25 -0400

Ah, dejá vu all over again...

I'll repeat the argument I made many moons ago that we should delete all 
references to anything called a "B2BUA", except to perhaps have an 
expansion of the acronym in our WG lexicon, and a statement somewhere, 
perhaps SIPCHANGE which says, in effect:

"A B2BUA is, loosely speaking, two SIP user agents glued together in 
completely unspecified ways. A SIP specification intended for standards 
track MUST NOT use the term B2BUA in any normative language. SIP 
specifications of any category SHOULD NOT use this term in descriptions of 
algorithms or protocol usage. The term MAY be used to compare alternatives, 
e.g. in requirements documents, or where the concept helps in elucidating 
the problem being addressed."

Dave.

>> > > Use [email-masked] for new developments on the

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Sep 2003 13:53:15 -0400

> track document, and merely notes in some BCP?

I can easily come up with cases where "one side fails, the other side 
should be brought down" is the wrong policy. Yes, it might be a good 
thing for some BCP.

I think that it is true that as long as a B2BUA acts properly as a UA on 
both sides then it is compliant. Any other limitations that might be 
imposed really apply to particular specializations of B2BUA that *could* 
be defined and standardized if somebody comes up with a good reason.

> I call it a B2BUA, and everyone is fine". 

Maybe we really do need to define the fabled "transparent B2BUA" to 
cover this case. But I suspect if we do that we will find disagreement 
on exactly how transparent it should be.

 > There are

Better to let people hang themselves with the rope we have given them. 
We can fix if we find too many dead people.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 5 Sep 2003 14:16:24 -0400

> of B2BUAs at all in any document other than 3261, 
> which is quite deliberately vague?
> 

Even that is not necessarily always true since
some b2bua's might want to connect the still
active side to treatments or trigger another call
to the dropped party.

> By your reckoning, would that be out of scope 
> for a standards track document, and merely notes 
> in some BCP?

Unless the standards track document is explicitly
associated with how one must or should implement
a particular category of b2bua, I do not think
that a document should impose a MUST or SHOULD
upon how a B2BUA bridges the two call halves.

> I've been seeing lots of B2BUA "misuse" lately.  
> The common one is "I have a proxy that modifies 
> headers, therefore I call it a B2BUA, and everyone 
> is fine".  There are no protocol police, and there 
> are no "architecture" police, but I think it is in 
> the community's interest to at least provide expert 
> guidance on how B2BUAs 'should' work. 
> This is an example.  'Should' is okay with me; 
> it would let your example be "legal".

The SHOULD is fine for some types of b2bua's.
However SHOULD NOT is more appropriate for other
types of b2bua's.  Thus I'd prefer the text
not be in the document.

---

From: Dean Willis <[email-masked]>
Date: Fri, 05 Sep 2003 14:22:21 -0500

Dave said:
> specifications of any category SHOULD NOT use this term in descriptions 
> of algorithms or protocol usage. The term MAY be used to compare 
> alternatives, e.g. in requirements documents, or where the concept helps 
> in elucidating the problem being addressed."

Well said. I think I'll add this to my .sig file.

--
Dean