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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 1 May 2014 10:57:00 +0300

Hi,

thanks for bringing this to my attention, Paul.

When the original offer/answer exchange (which includes the request for
"conf") completes the resources are already reserved. So, the answerer
does not need to send an additional offer. It will only need to send one
if the "threshold is crossed". That is, since the *initial* status has
already all the resources reserved, the threshold is not crossed. If the
resources were to be lost at some point, then an offer would naturally
need to be sent.

Cheers,

Gonzalo

On 30/04/2014 5:37 PM, Paul Kyzivat wrote:
> 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:
>> 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
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>