On 07/08/2008 06:13 PM, Dan Wing wrote:
Hadriel tried to carefully explain why SBCs change the body in
draft-kaplan-sip-uris-change-00.txt. It isn't because of NAT.
Please read draft-kaplan-sip-uris-change-00.txt.
Yikes. That's not a circus -- that's a abattoir. It's a very careful
analysis of why carriers want all of SIP except for the SIP part.
It looks like it boils down to:
4.1.1(a) - Some SIP products are broken by either design or
implementation
4.1.1(b) - Inter-service provider federation is being rolled out
without any of the tools the IETF has defined for that kind of thing
4.2 - Service providers won't deploy DNS, despite it being integral
to SIP and the Internet at large
4.3 - (Mostly a symptom of 4.2) People are deploying security
theater without any of the tools the IETF has defined for that kind
of thing, and tel: URLs aren't apparently supported, even when E.164
is the only useful identifier in use. (If you can change the domain
of a URI and still have it mean anything at all, it should have been
a tel: URL anyway)
4.4 - This isn't a stand-alone issue; it's a symptom of 4.1.1(b)
In short -- if we ignore the software bugs, it looks like the problems
all boil down the service providers choosing to ignore various
IETF-defined solutions (mostly as they relate to security). Why do we
think we can come up with a new security mechanism in the IETF and have
it make half a whit of difference to organizations who are clearly
hostile to IETF-developed security mechanisms?
/a
_______________________________________________
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
