Subject: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261

From: Adam Roach <[email-masked]>
Date: Tue, 30 Mar 2010 15:05:12 -0500

[as participant]

During the Anaheim meeting, I made an assertion that the optional 
feature of re-creating dialogs upon receipt of an in-dialog INVITE 
(i.e., one with a "To" tag) that did not match an ongoing dialog had 
been removed between RFC 2543 and RFC 3261.

I was wrong.

What I was recalling was a related change in handling; between 2543 and 
3261, the creation of such zombie dialogs changed from mandatory to 
optional (instead of going from "optional" to "prohibited," as I 
mistakenly recalled).

In 2543, the arrival of an apparently-in-dialog INVITE that didn't match 
an ongoing "call-leg" (dialog) would always create a new "call leg"; the 
called party had no way of rejecting the call with an indication that 
the associated "call leg" had been previously terminated (RFC 2543, 
section 10.1.1) -- the 481 response code had semantics only for CANCEL 
and BYE.

In 3261, the UAS is given the _option_ of re-creating the dialog under 
such circumstances. From 3261, section 12.2.2:

>     If the request has a tag in the To header field, but the dialog
>     identifier does not match any existing dialogs, the UAS may have
>     crashed and restarted, or it may have received a request for a
>     different (possibly failed) UAS (the UASs can construct the To tags
>     so that a UAS can identify that the tag was for a UAS for which it is
>     providing recovery).  Another possibility is that the incoming
>     request has been simply misrouted.  Based on the To tag, the UAS MAY
>     either accept or reject the request.  Accepting the request for
>     acceptable To tags provides robustness, so that dialogs can persist
>     even through crashes.  UAs wishing to support this capability must
>     take into consideration some issues such as choosing monotonically
>     increasing CSeq sequence numbers even across reboots, reconstructing
>     the route set, and accepting out-of-range RTP timestamps and sequence
>     numbers.
>
>     If the UAS wishes to reject the request because it does not wish to
>     recreate the dialog, it MUST respond to the request with a 481
>     (Call/Transaction Does Not Exist) status code and pass that to the
>     server transaction.
>    

In the interest of not digging into the actual details of the 
OPTIONS-related issues, I am intentionally refraining from commenting on 
the relationship between this behavior and the associated OPTIONS 
discussion topic from the Anaheim meeting.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 10:27:07 +0200

Hi Adam,

Mabye you were thinking about RFC 4028 (session timer)? It's a while since we worked on that draft, but I THINK we in some early versions had some text about session re-creation, which was later removed. And, based on a quick look, the RFC only talks about session re-fresh.

I think the usage of re-INVITE to re-create a dialog is bad, and will most likely cause all kind of issues. For example, there is no indication whether the UAC even wants the dialog to be re-created in the first place, in case it doesn't exist. And, in order to work any entity involved will have to be able to restore all resources (related to media, NAT traversal, security etc etc etc) from when the dialog existed - which means they have to maintain data for that dialog, and maybe even some procedures (keep-alives etc).

Now, I didn't see any question in your e-mail, e.g. wheter we should do something about this, but my opinion is still: do not allow it :)

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 30. maaliskuuta 2010 23:05
To: SIPCORE
Subject: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261

[as participant]

During the Anaheim meeting, I made an assertion that the optional feature of re-creating dialogs upon receipt of an in-dialog INVITE (i.e., one with a "To" tag) that did not match an ongoing dialog had been removed between RFC 2543 and RFC 3261.

I was wrong.

What I was recalling was a related change in handling; between 2543 and 3261, the creation of such zombie dialogs changed from mandatory to optional (instead of going from "optional" to "prohibited," as I mistakenly recalled).

In 2543, the arrival of an apparently-in-dialog INVITE that didn't match an ongoing "call-leg" (dialog) would always create a new "call leg"; the called party had no way of rejecting the call with an indication that the associated "call leg" had been previously terminated (RFC 2543, section 10.1.1) -- the 481 response code had semantics only for CANCEL and BYE.

In 3261, the UAS is given the _option_ of re-creating the dialog under such circumstances. From 3261, section 12.2.2:

In the interest of not digging into the actual details of the OPTIONS-related issues, I am intentionally refraining from commenting on the relationship between this behavior and the associated OPTIONS discussion topic from the Anaheim meeting.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 31 Mar 2010 09:22:59 -0500

On 3/31/10 3:27 AM, Christer Holmberg wrote:
> Now, I didn't see any question in your e-mail, e.g. wheter we should 
> do something about this, but my opinion is still: do not allow it :)
>

Sorry if I was unclear in the original email. It wasn't a question; it 
was a correction. I didn't want people laboring under a misconception 
because of my confusion.

This behavior is hardly something we need to go back and change in RFC 3261.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 21:48:47 +0200

So, you are saying that it is ok to re-crete dialogs using re-INVITEs?

If that's the way we want to go, fine. I just hope people actually won't start re-creating dialogs, because I think that could cause interop issues and state unsynchronization - without anyone to blame, since everyone can claim that they are acting according to the RFC...

Also, as I said earlier, I thought be decided that the session timer functionality could not be used to re-created dialogs. But, again, it's a while since we did that work, so...

Regards,

Christer

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: 31. maaliskuuta 2010 17:23
To: Christer Holmberg
Cc: SIPCORE
Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261

Sorry if I was unclear in the original email. It wasn't a question; it was a correction. I didn't want people laboring under a misconception because of my confusion.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 31 Mar 2010 16:39:29 -0500

[as individual]

> So, you are saying that it is ok to re-crete dialogs using re-INVITEs?

No, I'm pointing out that RFC 3261 says that. I have attached no moral 
value to that normative behavior.

Just because SIPCORE is chartered to work on core SIP protocol issues 
does not obligate us to challenge the validity of the normative 
statements in RFC 3261 whenever one is mentioned. The role of SIPCORE is 
to solve clear interoperability problems that people are actually 
experiencing, and extend the core protocol when doing so helps create 
new services. It does not serve us well to invent new problems where 
none exist, nor is it a worthy investment of time to create new tools 
that cannot be usefully made into actual features.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Apr 2010 08:57:56 +0200

Hi, 

>No, I'm pointing out that RFC 3261 says that. I have attached no moral value to that normative behavior.
>	
>Just because SIPCORE is chartered to work on core SIP protocol issues does not obligate us to challenge the validity of the normative statements in RFC 3261 whenever one is mentioned. The role 
>of SIPCORE is to solve clear interoperability problems that people are actually experiencing, and extend the core protocol when doing so helps create new services. It does not serve us well to 
>invent new problems where none exist, nor is it a worthy investment of time to create new tools that cannot be usefully made into actual features.

I agree.

But, before things are actually deployed, people are writing test specifications, designing protocol procedures for certain features and services, and they may find that difficult/impossible if the spec is unclear on how entities are supposed to behave.

Regards,

Christer