[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] sip-session-timer-11: why explicitly impose proxy restr ictions on all the b2bua's
Rosen, Brian wrote:
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.
Congratulations, you've perfectly restated the definition of B2BUA,
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?
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.
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?
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?
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".
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
_______________________________________________
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