Re: draft-kuthan-sip-derive

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