I remember when we were learning the limits in math analysis:
Definition Let (xn) be a sequence of real numbers. The sequence (xn) is said to converge to a real number a, if for all ε>0, there exists N in N such that |xn–a|<ε for all n≥N.
Take your time. Human brain simply have a problem to process more than two variables. Three is sometimes too much.
When I tell during a training that each dialog is identified by the triple Call-ID, From-tag and To-tag sometimes people start to experience the same kind of discomfort. So what are these headers for?
Call-ID (described in RFC 3261) is identifying a session. So in a common session the Call-ID will be the same in INVITE, PRACK, REFER, ACK, BYE and all the responses. Let’s say someone wants to establish a video chat with me. I have several active devices. Then I’ll receive the INVITE on each of them and they will contain the same Call-ID.
In SIP any dialog is possible between two end points – UAC/UAS only. If more parties are involved we can’t call it a dialog anymore (true :)). That means that the dialog is a subset of a session for particular UAs. And that is actually the reason why we need to add the tags into the identification of the dialog.
The SIP client adds the From-tag into the request. The recipient than adds the To-tag in the response. This helps to better identify the originator and recipient.
In case of the recipient the main reason is forking. Simply the recipient can use more devices and the one which will send 200 OK as the first (including its own To-tag) will be the one which will continue in the dialog.
In case of originator it can be the situation that originator is in a dialog with itself (because of testing purposes or so-called “hairpinning” of calls in PSTN gateways) and needs to distinguish between the originating and terminating end.
The identifiers have to be unique (across the time and space 🙂 ). Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. Tags are also helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure.
And last but not least it also explains another famous triple – INVITE, 200 OK, ACK. In the call flow above we can see why a 200 OK is not enough to start a media session. The most obvious reason for ACK is that the link is unreliable.
But it can also happen that more devices send 200 OK and the responding UAS can’t be sure that the 200 OK will arrive to UAC as the first one. So only the first UAC will receive the ACK and can start RTP session.
Mind that if any B2BUA is involved it can change Call-ID value and we need to follow two dialogs (UAC-B2BUA, B2BUA-UAS).
Authors of SIP and IMS were maybe very smart. But definitely they were not operation engineers. In practice it is not easy to trace all the messages which belong to a particular flow. Mostly we use the P-Asserted-Identity (and its equivalents such as X-XCAP-Asserted-Indentity or x-3gpp-asserted-identity) and we incrementally add new conditions in the filter. That’s why it is also kind of difficult to find a really good trace tools and many operators create them on their own.