Home > SIP, Telecom > SIP stories, part 1: dialogs

SIP stories, part 1: dialogs

This story is a long one. It tells about many things which I learnt about SIP lately. Maybe it will be useful for other fellow developers. It will be told in several subsequent articles. Here is a first part.

I must admit that for a long time I understood a concept of SIP dialog incorrectly. I correctly understood that the only purpose of dialog is that, once established, you can send subsequent messages for them. So, for end-points they provide session mechanism, and intermediate nodes can work statelessly. However, I wrongly believed that requests within a dialog could be sent only after succesful response on INVITE (or SUBSCRIBE). In other words, I thought that in-dialog requests are possible only for confirmed dialogs. Thus, I was wandering: why early dialog is needed? Later I added reliable provisional responses to my list of means of dialog confirmation, thus solving the problem of PRACK and UDPATE.

In a process of optimizing memory usage I’ve decided to shorten lifecycle of a dialog by removing early state at all. Fortunatelly, before doing this I sat and read very carefully about dialogs once more. And my point of view changed dramatically.

Dialogs in a present way were introduced because of just one protocol feature: proxy forking. Without forking life whould be much easier: INVITE whould start a dialog. But with forking, each recepient of INVITE should distinguish itself for sender by providing tag in “To” header. So, each end-to-end relationship (which is a definition of a dialog, by the way) could be defined only after first response with tag in “To” header. Tag for “From” header was added just for symmetry.

If a recepient of INVITE has answered with provisional response containing tag in “To” header, then later it must supply exactly the same header in other provisional and succesful responses, because otherwise sender will think that those responses come from different UAS. When answering with error response a tag is not nesessary, because error response terminates all dialogs started for INVITE, no matter from which UAS it was sent.

Thus, all components used for matching request against dialog (Call-ID, and tags) will not change after first response, even if this response is a provisional one. It means that (contrary to my belief) there is no problem in sending in-dialog requests for early dialog. Then, what is the difference between an early and a confirmed dialogs ? Here they are:

  1. Early dialog will terminate when error response on INVITE will be received. Confirmed dialog is terminated by sending or receiving BYE request
  2. When transitioning from early state to confirmed state, a route set can be re-computed. In confirmed state, route set is never re-computed.

After I’ve learnt all these things, I’ve changed my implementation. The code became much clearer, because I’ve removed all methods like “matches()” which checked responses and requests against dialog in some custom (and incorrect) ways. The only correct way of retrieving a dialog is by comparing dialog ID calculated from contents of the message with dialog ID of internal representation of dialog. HashMaps work perfectly for this task.

However, the changes I’ve made had a very interesting consequences.

Categories: SIP, Telecom Tags:
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: