Home > SIP, Telecom > SIP stories, part 3: INVITE retransmission

SIP stories, part 3: INVITE retransmission

A second use case which broke after I’ve implemented strict dialog matching was a case of INVITE retransmission. When UAS immediatelly answers to INVITE with “200 OK” response, it terminates server transaction. If this response will not be delivered to UAC, then UAC will retransmit an INVITE. However, UAS will treat retransmission of INVITE as a new request, because the server transaction is terminated, and the INVITE doesn’t have a tag in “To” header. This is another serious flaw in RFC 3261.

As with previous case, I’ve used custom matching of INVITE against dialogs, based on Call-ID, tag of “From” header and URI of “To” header. It was a dirty hack, but it worked. I’ve looked at NIST SIP stack and Sailfin to see how they handle this problem, and it seems that these stacks have not solved it. I couldn’t believe that I alone have encountered this problem in RFC 3261.

After some search I’ve discovered a document which addresses both this and previous problems. It’s a  internet draft which may later become another RFC. It’s a first document which proposes fixing RFC 3261 instead of extending it. The main idea is to change state machines for INVITE client transactions and INVITE server transactions. So, if this draft will turn into RFC, then hack used in Sailfin will not be a hack after all, because it is very similar to approach proposed in this draft.

As for me, I totally agree with state machine extension. After some analisys I’ve came up with a situation when a proxy has the same problem with several succesfull responses on an INVITE as UAC has. So, the problem should be fixed at a common layer of UA and proxy, which is transaction layer.

I’ve already implemented the approach of that draft, because I believe that having working solution is better then following broken RFC 3261. I can’t believe that someone will rely on broken behaviour and will demand SIP stack to follow it. This new solution is nicer than my previous hacks because I have cleaner code. I don’t even have a method which matches responses against dialogs, because it is not nesessary anymore, and it can give better performance. As a drawback there is a longer lifetime of transactions, which consume memory. But I think it is acceptable.

If my opinion matters, I totally support this internet draft and wish it becomes an RFC. My big “thank you” goes to Mr. Robert Sparks who did it. I just wander why this internet draft was published only recently ?

That’s the end of the long “dialogs, forking and races” story. I hope someone will find it useful. If I’ll encounter some other problems with protocol, I’ll surely share it in another article of “SIP stories”.

Categories: SIP, Telecom Tags: , ,
  1. Varchas
    January 29, 2009 at 7:03 am

    Hello . .I totally agree to your views. Even we have found the RFC a little vague in some places. .. Though I must admit I have not gone through your comments in detail …will get back to you once we have gone through it.

  2. whitelassiblog
    August 15, 2009 at 9:22 am

    excellent !

  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: