[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.

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 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'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".
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
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".
Better to let people hang themselves with the rope we have given them. We can fix if we find too many dead people.

Paul


_______________________________________________
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