Dan Wing wrote:
[JRE] This is a pointless exercise if it can't be deployed without
fixing SIP intermediaries that are out there at present, and many of
these are B2BUAs. This is similar reasoning to that which says that it
has to work with the majority of UAs out there at present.
There has to
be a good chance of the mechanism working in the majority of
inter-domain situations, and sadly that will nearly always involve
B2BUAs of some form, and sadly this means a lot of things in SIP
messages get changed. We can't do much about B2BUAs that are
deliberately trying to stop things working, but we should at least try
to take account of B2BUAs that are going about their legitimate
business. Otherwise this will be yet another SIP RFC that never or
rarely gets deployed.
Let's steal a pagebook from the PSTN, circa the early 1990's, when
disable-echo-cancellation tones were introduced. As everyone probably
remembers, they were necessary for the >9600bps modems and fax machines. At
the time, no PSTN equipment understood the disable tones so nobody could use
their fancy 14.4kbps modem at 14.4kbps. But as time went on more PSTN
equipment understood the disable tones and eventually you could almost always
get a >9600bps speed connection. It did not happen overnight, and did not
happen immediately. People that bought the faster modems were often unhappy
they could not use the faster speed. But the specification was written,
intermediaries (Service Providers) agreed it caused them no harm, eventually
the intermediary equipment understood the disable-echo-cancellation tones.
Briefly, world hunger was solved.
If that situation doesn't ring with some familiarity, there are many other
situations where where intermediaries had to upgrade in order for the end user
to benefit: unleaded gasoline; airport runways long enough for passenger
jets. I'm sure more creative people can think of other situations where this
worked well. Obviously there are zillions of counter examples as well (e.g.,
hydrogen powered cars are not viable due to insufficient numbers and poor
distribution of hydrogen fueling stations; supersonic flight over continents
is not viable because the people living on the continent do not generally
enjoy the supersonic boom).
Hi Dan and John,
I actually do have a counter-example which makes me a bit worried -- NATs.
(not meaning to disagree ... just trying to understand the evolution cycle)
Think of IP addresses in application payload with NATs. That appears
remarkably
similar as reference to a call in SUB/NOT in DERIVE, which -- if not
translated
by the B2BUA that translates it in callid/to/from header-field -- will fail.
Obviously ignoring NATs didn't work quite well.
I would tend to be pragmatic and like to make DERIVE B2BUA-resilient, I'm
just failing to see how. If a UA can be smart and robust enough to deal
with strange things in the network, why don't we do that. The problem is
really I don't see a clear way of doing that. To my best knowledge, there
is not a single piece of SIP message which a B2BUA would guarantee to
deliver to the other party. The notion of B2BUA is largely unspecified
in its behaviour.
We could try to guess a behaviour of a "resonable B2BUA". For example we
could assume that if we don't put dialog references in payload (e.g. by
using
an in-dialog new-method IS-IT-YOU request), the dialog reference will be
translated like for the initial INVITE and things will work.
So in summary these are IMO the options to deal with it:
a) ignore B2BUA traversal in anticipation if they break something,
they will be motivate to fix it
b) align the design to something we guess has a better chance
to get through B2BUAs without a normative reliance on their
behaviour (but what could it be???)
c) in addition to a/ or b/, do B2BUA-BEHAVE :)
Aside from architectural and evolution arguments on both a and b, does
anyone
have an opinion on what can safely get through the B2BUAs?
-jiri
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
