Yet another of the subtle and not-very-thought-out details of SIP has shown its ugliness to me again today.
REGISTER
Great concept, extremely poor execution.
When you send a REGISTER request (which, for the uninitiated maintains a binding for where you can be reached), you have to always send it with the same CallID and an monotonically increasing CSeq (sequence) number. Sounds simple. Except it kinda breaks a whole bunch of things about SIP.
You aren't supposed to use the same CallID unless you are inside a dialogue... unless it is a register. This basically means the protocol is asymetric and any implementation must have special rules for special messages. In this case, we need a special rule that means that we can supply our own CallID and CSeq for a REGISTER message, but no other messages. The implication is that any correctness checking before sending off a transaction has to have a special case for REGISTER.
Why do I care?
SIP isn't just some hobby protocol anymore. It is quickly on its way to replacing inter-carrier trunks and is basically the defacto new standard for phone calls. How can we expect the same level of reliability from the network if the protocols are insanely complex? We are now on the second version of SIP. The RFC has 269 pages, there are 26 other related RFCs and some 30 drafts for new RFCs (and counting). There has to be some consolodation on this, otherwise it will be meaningless to say that you are "SIP Compliant" or have "SIP Interoperability" etc.
A Better Way
REGISTER messages have to be re-sent every so often to maintain the bindings in the registrar. This is a reasonable method of determining if the client is still there, or if it crashed, or the network went away. When you want to remove the bindings (you close the client), you send a request to expire all of them. This sounds like a session to me.
Why wasn't the registration concept implemented similar to the INVITE? INVITE transactions expire after a while unless you refresh them (basically a ping/ack mechanism inside the dialogue to keep the signaling alive, and detect dead calls). Couldn't REGISTER have been modeled the same way? Wouldn't having REGISTER be a dialogue and using the same type of refresh model have made it easier? For that matter, couldn't you really have accomplished the same thing by sending an INVITE, but instead of having a session description in it to establish a call, or a conference, or a text chat, etc., you indicated that it was a registration?
Mirror, Mirror
When designing any protocol, the goal should be orthogonality. Special rules should be a red-flag that you are doing something wrong. Go back, re-think, and hopefully come up with a better design. Sometimes special rules have to exist, but they should be avoided.
SIP is in no way orthogonal.
3 comments:
Your idea about using INVITE to manage the registration session seems to make a lot of sense. I think the rationale behind using a separate REGISTER was that it could be done a lot simpler than INVITE. Of course that would have led you or I to ask, "Why is INVITE so complicated I don't want to use it for this?" :)
Doing anything like this may have broken the goal to have a peer-to-peer session establishment. The idea was that you would just "go find out where Alice is and contact her directly" when in reality you can't because Alice has a firewall, and is inside a NATed network.
From conception SIP never really accounted for those things. The idea was good, but implementation outside of a totally open network is impossible. This is why you are starting to see extensions to SIP that basically break the peer-to-peer goals.
Turns out this is another case of "SHOULD" in a RFC making things unclear.
The message SHOULD have the same CallID, but doens't have to. Ugh.
Post a Comment