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

From: [email-masked] (Dale R. Worley)
Date: Thu, 12 Nov 2015 16:58:27 -0500

Christer Holmberg <[email-masked]> writes:
> 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).

It seems to me that 491 is not a good solution to this problem.

Compare to the situation where the application server received the
SUBSCRIBE if it hadn't sent the re-INVITE.  Presumably the AS would
respond with 404, 489, or some such.  Presumably that's what the AS
should respond to in this race condition, as the AS isn't yet ready to
provide notifications for this address/event combination.

As Robert says, why can't the AS accept the subscription in some sort of
inchoate state until it receives the 200?

But more to the point, what is the specification of when the UA can
subscribe to that event from the AS?  Either the UA is allowed to
subscribe as soon as the re-INVITE is sent (in which case, the AS should
accept the subscription), or the UA is not allowed to subscribe until
the AS changes state (in which case, the UA should wait until it
receives the ACK).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Nov 2015 21:24:54 -0500

>> event package (conference, afaik) to the application server.

Is this an in-dialog SUBSCRIBE, or out-of-dialog?

Is the UA planning to wait for a response to the subscription before 
responding to the re-INVITE?

>> the SUBSCRIBE (exactly why I don't know).

This would be easier to follow if we knew what event package this was, 
so we could understand the dependency. I'm inclined to think such a 
dependency should not be imposed.

> SUBSCRIBE if it hadn't sent the re-INVITE.

Or, if it received the subscribe out-of-dialog.

> Presumably the AS would
> respond with 404, 489, or some such.

Again this may be about in- or out-of- dialog.

> Presumably that's what the AS

I don't know about that. I might buy it if this was happening on the 
initial invite. But it is less believable for re-invite. What possible 
state can the re-invite be establishing that must be waited for?

I'm inclined to guess that the server simply can't handle two concurrent 
transactions on the same dialog. *That* is a bug, especially if it is 
trying to manage two dialog usages in one dialog.

	Thanks,
	Paul