Subject: [sipcore] Precondition and status confirmation requested by offerer

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 30 Apr 2014 14:07:14 +0000

Hello,

can you please help me with a question related to precondition handling in RFC3312?

Scenario:

Bob receives an SDP offer O1 containing (not all lines are shown):

      m=audio <port> <proto> <fmt>

      a=curr:qos local sendrecv

      a=curr:qos remote none

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

      a=conf:qos remote sendrecv

Bob has needed resources and generates and sends an SDP answer A1 containing (not all lines are shown):

      m=audio <port> <proto> <fmt>

      a=curr:qos local sendrecv

      a=curr:qos remote sendrecv

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

Question:

Does "a=conf:qos remote sendrecv" included in SDP offer O1 mandate Bob to send an additional SDP offer O2 immediately after sending the SDP answer A1?

RFC3312 seems to mandate sending such additional SDP offer since it states:

--------------------

   The confirm-status attribute MAY be used in both offers and answers.

   This attribute represents a threshold for the resource reservation.

   >>When this threshold is reached or surpassed, the user agent MUST send

   an offer to the peer user agent, reflecting the new current status of

   the media line as soon as allowed by the SIP offer/answer rules<<.  If

   this threshold is crossed again (e.g., the network stops providing

   resources for the media stream), the user agent MUST send a new offer

   as well, as soon as allowed by the SIP offer/answer rules.

   >>If a peer has requested confirmation on a particular stream, an agent

   MUST mark that stream with a flag in its local status table.  When

   all the rows with this flag have a "Current" value of "yes", the user

   agent MUST send a new offer to the peer.<<  This offer will contain the

   current status of resource reservation in the current-status

   attributes.  Later, if any of the rows with this flag transition to

   "No", a new offer MUST be sent as well.

--------------------

However:

- sending of such additional SDP offer O2 should not be necessary since SDP answer A1 indicates that Bob's resources are reserved.

- if order of the SDP answer A1 and the additional SDP offer O2 is swapped on the way to the remote UA, then the remote UA rejects the UPDATE request carrying the additional offer O2 with 491 (Request Pending) response.

The situation above occurs with third party call control. I am aware that in regular two party calls, it should not occur.

Kind regards

Ivo Sedlacek

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Apr 2014 10:37:33 -0400

Ivo,

I just skimmed this, but before digging into it I think we need to 
settle on the proper place to discuss it. My first thought was that it 
is not really a sip thing and ought to be discussed in mmusic. But 
looking back I see the the drafts leading to 3312 were processed in the 
sip wg. Since sipcore and dispatch are the descendents of the sip wg, 
maybe sipcore isn't wrong. Normally I would say that mmusic would be the 
right place to deal with a SDP issue such as this. But mmusic is fully 
engaged in other things now, and this would likely get lost there. So 
for the time being I guess we might as well discuss it in sipcore.

Perhaps we can have an opinion on this by Gonzalo, since he was editor 
of 3312 and its update 4032.

	Thanks,
	Paul

On 4/30/14 10:07 AM, Ivo Sedlacek wrote:
> Does "a=conf:qos remote sendrecv" included in SDP offer O1 mandate Bob
> to send an additional SDP offer O2 immediately after sending the SDP
> answer A1?
>
> - sending of such additional SDP offer O2 should not be necessary since
> SDP answer A1 indicates that Bob's resources are reserved.
>
> - if order of the SDP answer A1 and the additional SDP offer O2 is
> swapped on the way to the remote UA, then the remote UA rejects the
> UPDATE request carrying the additional offer O2 with 491 (Request
> Pending) response.
>
> The situation above occurs with third party call control. I am aware
> that in regular two party calls, it should not occur.
>
> Kind regards
>
> Ivo Sedlacek
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>