[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Liaison Statement on offer/answer procedures
Regarding SDP:
I think the likely candidates are:
1) as specified in 3261, and contrary to 3264, if a reinvite fails,
the SDP/media-session state rolls back to what it was before the
reinvite. This is so even if there answers were transmitted reliably via
PRACK and/or UPDATE.
2) Once an answer has been transmitted reliably, it is committed, and is
not rolled back if the reinvite subsequently fails.
Of these, (2) is probably easier to understand and implement. And its
probably semantically reasonable, except for one case:
That case relates to preconditions. Using preconditions, you can get
into a state where an offer/answer has completed, but preconditions have
not been satisfied, so the media stream is not usable. It is then
expected that a subsequent o/a exchange will improve upon this, and
eventually result in usable media streams. If each o/a is committed
independently, then a previously working can be replaced with an
unusable state until a further o/a fixes it, and if a further o/a
doesn't fix it then it remains permanently broken.
(An example of this might be starting from a working low bandwidth audio
session. A reinvite is then sent with an attempt to upgrade to a
wideband codec with preconditions used to condition the change on
obtaining sufficient bandwidth. In this case you would like to continue
to use the low bandwidth codec until you know if you have obtained the
resources for the wideband.)
Note that this problem exists even without reinvite. It can occur if an
update to a working session is initiated using UPDATE with preconditions.
IMO this is an intrinsic problem with preconditions. Because they aren't
widely used, it may be prudent to split off fixing that as a separate
task. If that is done, then I think (2) above is probably a good way to
solve the rest of the problem.
To solve the precondition problem I think we need a concept like
o/a-transaction. A single o/a pair is an o/a-transaction if it contains
no unsatisfied preconditions. But an o/a that has unsatisfied
preconditions results in an incomplete o/a-transaction. Additional o/a
pairs continue to be part of it until a final o/a pair where the
preconditions are satisfied. That ends the o/a-transaction. A failure in
the midst of an o/a-transaction (signaled in the enclosing protocol like
sip) would revert to the session state in effect before the beginning of
the o/a-transaction.
I would expect this direction for preconditions to be controversial.
(Among the one or two people who actually care about preconditions.)
Which is a good reason to split it off from the rest.
Thanks,
Paul
Christer Holmberg wrote:
> Hi,
>
> I agree with Paul that we probably aren't talking about changes to 3264 here.
>
> Also, I am fine if we want to decouple "committings" of media data/SDP updates with other types of data updates (contact etc).
>
> But, that means that we need to specify specific "committing" rules for any type of data which can be affected. Or, we can of course have a "default committing rule" (e.g. full rollback), and then specify different rules for specific type of data when/if needed.
>
> But, for the SDP data, would anyone object to a full rollback?
>
> Regards,
>
> Christer
>
> ________________________________
>
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Wed 04/06/2008 17:32
> To: Gonzalo Camarillo
> Cc: Christer Holmberg; Elwell, John; sipping List; Mary Barnes
> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>
>
>
> Gonzalo,
>
> I generally agree with your characterization below. But as I see it
> there likely are no changes needed to 3264. It is intentionally focused
> on the SDP, and not the conveyance of the SDP in some containing
> protocol. The following is about the extent of it in 3264:
>
> Protocol operation begins when one agent sends an initial offer to
> another agent. An offer is initial if it is outside of any context
> that may have already been established through the higher layer
> protocol. It is assumed that the higher layer protocol provides
> maintenance of some kind of context which allows the various SDP
> exchanges to be associated together.
>
> The agent receiving the offer MAY generate an answer, or it MAY
> reject the offer. The means for rejecting an offer are dependent on
> the higher layer protocol. The offer/answer exchange is atomic; if
> the answer is rejected, the session reverts to the state prior to the
> offer (which may be absence of a session).
>
> SIP messed this up somewhat with the offerless-invite, and more when it
> introduced PRACK and UPDATE. The offerless-invite creates a case when it
> is impossible to reject an offer. But we aren't discussing that case
> here. Without PRACK and UPDATE, and with an offer in the INVITE, it the
> success or failure of the INVITE that determines the acceptance or
> rejection of the offer. (With an offerless invite, the ACK always
> accepts the offer, for better or worse.)
>
> The use of PRACK and UPDATE while an INVITE transaction is is progress
> creates an ambiguous situation due to the following from section 14.1 of
> 3261:
>
> If a UA receives a non-2xx final response to a re-INVITE, the session
> parameters MUST remain unchanged, as if no re-INVITE had been issued.
>
> This implies that changes made via PRACK and UPDATE during the INVITE
> transaction must be rolled back. Since the problem created by 3262 and
> 3311, in conjunction with 3261, I think the fixes will have to apply to
> those, not to 3264.
>
> Also, the issue about changing Contact addresses clearly has nothing to
> do with 3264. And I am becoming increasingly convinced that the rules
> for "committing" a change of Contact address ought to be decoupled from
> the rules for "committing" a change to media sessions.
>
> Before we get into the specifics, does the above make sense?
>
> Thanks,
> Paul
>
>
>
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> we should be providing 3GPP with an answer to their liaison soon:
>>
>> https://datatracker.ietf.org/liaison/444/
>>
>> The thing is that when working on the offer/answer usage draft below, we
>> kept from making normative changes to offer/answer:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
>>
>>
>> However, it seems that there are a few cases that would require
>> normative updates to RFC 3264. In this thread, two cases have been
>> identified: roll back and address changes during ongoing transactions. I
>> would like to see a list of such pending updates in order to decide
>> whether we need to revise RFC 3264 at this point or document the current
>> issues (like we are doing with RFC 3261) for a future update.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>>
>> Christer Holmberg wrote:
>>> Hi,
>>>
>>> I do NOT think John's case is connected to the rollback issue.
>>>
>>> The rollback issue is: what happens to data that has been updated
>>> between the re-INVITE request and failure response? It of course
>>> included the target, but is not related to where responses are sent.
>>>
>>> Responses are, afaik, always sent to where the request came from, so
>>> if one updates the local target he has to make sure that he listens to
>>> the "old" port if there are ongoing transactions.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> ________________________________
>>>
>>> Lähettäjä: Paul Kyzivat [mailto:pkyzivat at cisco.com]
>>> Lähetetty: pe 16.5.2008 14:38
>>> Vastaanottaja: Elwell, John
>>> Kopio: Christer Holmberg; sipping List
>>> Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures
>>>
>>>
>>>
>>> John,
>>>
>>> This is a good point.
>>>
>>> It does expose a potentially long window when address changes are
>>> problematic. I guess if a quick address change is necessary then the
>>> INVITE, or reINVITE, can be CANCELed.
>>>
>>> IMO this is starting to identify an area that could stand to have more
>>> specification. I guess this sounds like a best practices draft, but its
>>> still a little fuzzy to me. And I am far from clear whether this is
>>> tightly connected to the o/a rollback issue.
>>>
>>> Thanks,
>>> Paul
>>>
>>> Elwell, John wrote:
>>>> Paul,
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: sipping-bounces at ietf.org
>>>>> [mailto:sipping-bounces at ietf.org] On Behalf Of Paul Kyzivat
>>>>> Sent: 15 May 2008 14:48
>>>>> To: Christer Holmberg
>>>>> Cc: sipping List
>>>>> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>>>>>
>>>>> Christer,
>>>>>
>>>>> Saying "you shouldn't do it" to changing contact address or media
>>>>> address ignores facts of life that may require doing it. This
>>>>> overlaps
>>>>> strongly with the session mobility discussion that is
>>>>> currently going on.
>>>>>
>>>>> Specifically, if a UA is losing possession of its address, or
>>>>> connectivity via that address, then it will have to do
>>>>> *something*. If
>>>>> we are going to say that you shouldn't change the contact
>>>>> address in a
>>>>> dialog, and shouldn't change the media address in a media
>>>>> session, then
>>>>> we need to specify some alternative.
>>>>>
>>>>> Clearly there are at least two distinct cases here:
>>>>>
>>>>> - there is a desire to switch to a new address, but the old address
>>>>> can continue to be supported until and unless use of the new one
>>>>> can be established
>>>> [JRE] So if the contact address changes and we successfully conclude the
>>>> UPDATE transaction, and then the old contact address disappears, it is
>>>> likely that the Via list on the re-INVITE request will have become
>>>> invalidated too, so the final response will not reach the UAC. Correct?
>>>>
>>>> John
>>>> _______________________________________________
>>>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>>>> This list is for NEW development of the application of SIP
>>>> Use sip-implementors at cs.columbia.edu for questions on current sip
>>>> Use sip at ietf.org for new developments of core SIP
>>>>
>>>
>>> _______________________________________________
>>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use sip-implementors at cs.columbia.edu for questions on current sip
>>> Use sip at ietf.org for new developments of core SIP
>>>
>>
>
>
>
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP