Subject: [sipcore] 491 for non-INVITE/UPDATE/PRACK

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Oct 2015 11:32:41 +0000

Hi,

The 491 response code was introduced in RFC 3261 in order to deal with re-INVITE race conditions. RFC 3311 extended the usage to UPDATEs and PRACKs carrying SDP offers.

My question is: is it allowed to use 491 for other methods and cases, where the application determines that a request cannot be accepted due to another outstanding transaction on the same dialog? RFC 3261 does not explicitly forbid it, as far as I know.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Oct 2015 10:31:51 -0400

On 10/6/15 7:32 AM, Christer Holmberg wrote:
> Hi,
>
> The 491 response code was introduced in RFC 3261 in order to deal with
> re-INVITE race conditions. RFC 3311 extended the usage to UPDATEs and
> PRACKs carrying SDP offers.
>
> My question is: is it allowed to use 491 for other methods and cases,
> where the application determines that a request cannot be accepted due
> to another outstanding transaction on the same dialog? RFC 3261 does not
> explicitly forbid it, as far as I know.

Can you be more specific about the case?

I am inclined to say Yes. But I think this probably should be handled on 
a case by case basis, to ensure that some other code wouldn't make more 
sense, or that a new code is really needed.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Oct 2015 20:02:06 +0000

Hi,

>> to another outstanding transaction on the same dialog? RFC 3261 does 
>> not explicitly forbid it, as far as I know.
>
> I am inclined to say Yes. But I think this probably should be handled on a case by case basis, to ensure that some other code wouldn't make more sense, or that a new code is really needed.

The case is the following (high-level, as I am not aware of the details):

1. An application server sends a re-INVITE, with an updated offer, to a UA
2. When the UA receives the re-INVITE, it sends a SUBSCRIBE for an event package (conference, afaik) to the application server.
3. The application server receives the SUBSCRIBE before it receives the response to the re-INVITE, so it rejects the SUBSCRIBE with 491. It wants to get the response to the re-INVITE before it accepts the SUBSCRIBE (exactly why I don't know).

The UA seems to be 3265 compliant, as it sends the SUBSCRIBE within the invite dialog. However, that problem would be the same even if the SUBSCRIBE was sent on a different dialog. I guess the response code may be different, because the 3261 text about 491 does talk about pending transactions *within the same dialog*.

Now, IF we would allow general usage of 491, then it would be perhaps be good to also indicate exactly *which* pending transaction triggered the 491. Perhaps the transaction-id could be used for this.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Tue, 6 Oct 2015 15:39:24 -0500

On 10/6/15 3:02 PM, Christer Holmberg wrote:
> 3. The application server receives the SUBSCRIBE before it receives the response to the re-INVITE, so it rejects the SUBSCRIBE with 491.
The semantics here are wrong. 491 in that case does not make sense.

This isn't "you have glare, back off and try again", which is where 491 
is used so far.

It's "I don't have the application state you are looking for (yet). 
Please try again later" (or at least, that's what I can infer from your 
description so far)."

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Oct 2015 20:50:39 +0000

Hi,

> This isn't "you have glare, back off and try again", which is where 491 is used so far.
>
> Please try again later" (or at least, that's what I can infer from your description so far)."

So, do we have a response code for that? :)

I was looking at 500, 503 etc, but I am not sure that they really fit either.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Tue, 6 Oct 2015 16:01:17 -0500

500 is probably the best, in the generic case, but I'm still trying to 
wrap my head around the scenario as you've described it. Wanting to 
reject a SUBSCRIBE to the conference event package for the reason given 
seems like the application is doing something unusual/unexpected with 
that event package.

Can you double-check that it's the conference and not the dialog package?

Whichever it is, what's the motivation for not just accepting the 
SUBSCRIBE and waiting for the right application state to come in to send 
the relevant NOTIFY? Is it that they can't figure out a reasonable 
immediate NOTIFY to send?

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Oct 2015 18:03:35 -0400

> 2. When the UA receives the re-INVITE, it sends a SUBSCRIBE for an event package (conference, afaik) to the application server.

Is this a coincident occurrence of two unrelated events, or is the 
re-INVITE causing the UA to send the SUBSCRIBE?

Also, is this creating a new subscription, or refreshing an existing 
one? Or is it a polling subscribe?

(I don't know if the answers to the above will have any effect on the 
ultimate answer. I'm just trying to grasp what is going on.)

	Thanks,
	Paul