The SIP ConSIPracy.
Rosybug> Hmm how can i make money from this silly PhD
paper.
Rosybug> I know, I'll make it a 'standard'
Rosybug> But I will make it so complex that companies
will have to buy my implementation to be standards
compliant.
Complexity steps.
+++++++++++++++++
company confidential, DO NOT REDISTRIBUTE.
1) All call control has to go over UDP, yea! now all
client apps will have to reinvent reliable transport
over UDP.
SOLUTION: Call control MUST be over TCP, doh.... and
never UDP. Forget SCTP. (oh looks like bis 8 makes TCP
support mandatory LOL worst of both worlds)
2) Lets write the grammar in ABNF because there are no
ABNF compiler compilers out there. This means I will
get to fly all over the world doing SIP bake offs.
SOLUTION: Could have used XML for call control
messages, then we would not need a silly sip stack.
XML:- is human readable.
DTD would replace sip grammar.
many parsers available in many languages.
3) Lets add a plethora of additional SIP add on specs
to overcome the built in desgin problems.
e.g. SIP Timer(kludge): how do we know when the remote
client has gone when the network cable was cut and the
BYE message was never received?
4) Media description.
I know about SDF 'cos I wrote that, and I really don't
care that SDF is not well suited for use in SIP, not
invented here==must be cr*p.
Let's see:-
SDF has an IP address (c=IN IP4 x.y.z.a) and
port (m=gibberish <port> more gibberish <media
format>)
We also have a load of mandatory fields that seem to
duplicate the SIP fields or are redundant.
(o=gibberish) Duplication = confusion = more $$ for
me.
LOL satirical ;))))
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
