On Jul 14, 2008, at 11:32 AM, Byron Campen wrote:
On Jul 13, 2008, at 12:49 PM, Hadriel Kaplan wrote:
But for a lot of cases they're not modifying To/From for that
reason - they're modifying it to either "fix" them for specific
interop reasons, or to hide topology (ie, when it contains IP
Addresses or hostnames). Those are the cases I'm trying to get
the information through.
DY> Just to add to what Hadriel said, one of the additional
arguments *for* an SBC that I've had given to me by different
vendors at various shows is that they can "normalize" SIP and make
SIP interoperability actually work between different vendors. The
SBC understands how exactly Vendor X speaks SIP and how exactly
Vendor Y speaks SIP and can then enable the interconnection/
interoperability. So the reality is that there are SBCs out there
that view as part of their function to "fix" SIP so that it can be
interoperable. In doing this "fixing", one can expect that the
SBCs would be changing headers.
I would say I don't know whether I should laugh or cry, but
laughter is obviously much more fun. Seriously; how ridiculous do
things need to get before we can no longer keep a straight face? (I
gave up a while ago)
You're right, it's a Really Big Mess.
There are several mistakes we've made again and again that got us
where we are:
1) Writing specifications dramatically ahead of implementation
experience.
2) Hacking up bits of our core protocol model to appease the adherents
of strict interworking with legacy phone systems, and accepting broken
requirements from the same.
3) Using MUST to describe "does" in explicative text, thereby
preventing RFC 2119 language from being useful in tabular comparison
of implementations to the specification or to other implementations.
4) Multiple ways of doing things, including a P-header appeasement
thing vs a "standard" solution.
5) Failure to deprecate the specifications and pieces of specs that
either don't work or don't get used.
6) Demanding "perfect" security in the specification, when we know
quite well that nobody will implement the security features,
especially if they're hard to build or operate.
6) Refusal to deprecate a whole lot of cruft and revise the version
number of the protocol. Trying to negotiate backward compatibility for
every design mistake we ever made is a nightmare. Let's at least find
a way to make this a bounded problem.
6) Listening to me when I'm wrong.
6) Not listening to me when I'm right.
7) Trying to count our mistakes on our fingers while we're busy typing.
--
Dean
_______________________________________________
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
