Re: [Sipping] Liaison Statement on offer/answer procedures

["Christer Holmberg" <[e-mail]>]

>What about backward compatibility with UA which do not follow this manual rollback mechanism?
 
What about backward compability with UA which doesn't do full fallback, if we chose that altenative?
 
I don't think there are - yet - too many implementations out there doing re-INVITEs with intermeidate offer/answer in the first place, so I don't think backward compability is a big problem.
 
But, I can forsee implementations that WILL implement this (this is the reason 3GPP need a solution, for example), so therefor I think it is important that we make a decission now.
 
But, to answer your question:
 
In a pre-condition case there are most likely going to be resources reserved for no good, and I am sure either/both user is going to detect that things don't work as they should (a UAC that wanted to add a media stream is not going to get any media from the other end, which rejected the re-INVITE, etc).
 
Regards,
 
Christer


>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Christer Holmberg
>Sent: Saturday, June 07, 2008 7:59 PM
>To: Paul Kyzivat (pkyzivat)
>Cc: Elwell, John; Mary Barnes; sipping List; Gonzalo Camarillo
>Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>
>Hi,
>
>>>>>>> - If an UPDATE (inside or outside of a reINVITE) fails, any o/a
>>>>>>> in the UPDATE has no effect on the media session state.
>>>>>>> [Ian Elz ] OK, but how will we determine if an UPDATE is inside
>>>>>>> or outside a re-INVITE?
>>>>>> [Christer] I assume that any stateful entity must know
>whether it
>>>>>> has a pending re-INVITE transaction for a specific call or not.
>>>>> That's not actually enough. A UAS (or dialog stateful
>proxy) cannot
>>>>> know whether an UPDATE received shortly after a 2xx is sent
>>>>> upstream was sent before or after the 2xx was received by
>the UAC.
>>>>> We could add an explicit indication to that effect, I suppose...
>>>> Yes. Taking this approach to the current problem requires that we
>>>> find a solution to knowing whether the update was sent
>inside the reinvite or not.
>>>
>>>If the UAS sends a 2xx response to the re-INVITE I guess it
>really doesn't matter when the UPDATE was sent.
>>
>>>But, if the UAS sends a non-2xx response to the re-INVITE I
>guess it would need to know when the UPDATE was sent: was it
>sent still assuming that the re-INVITE will succeed, OR was it
>sent bacause the re-INVITE did NOT succeed?
>>
>>>If we would go for the non-rollback alternative we wouldn't
>have this problem since the re-INVITE failure response doesn't
>affect UPDATE/PRACK offer/answers, and then it doesn't matter
>when the UPDATE was sent.
>>
>>Exactly! That is an advantage of the non-rollback solution.
>>But the rollback solution has the advantage of providing a
>solution to
>>the precondition rollback problem.
>>
>>We need to pick our poison.
>
>Let's discuss the non-rollback alternative for a while.
>
>For the pre-conditions case, when the re-INVITE fails, it most
>likely means that the UAS finally chose not to accept whatever
>was proposed in the re-INVITE request (maybe a new stream).
>Now,  before the re-INVITE failure response, intermediate o/a
>transactions may have succeeded, resources may have been
>reserved etc, e.g. because the UAS user wasn't "asked" about
>the new stream until a certain point.
>
>So, since the re-INVITE failure response now wouldn't affect
>the suceeded intermediate o/a transactions, I guess the UAC
>(or UAS) would have to initiate a "manual fallback", by
>sending a new re-INVITE/UPDATE offer, with the SDP that was
>used before the previous failed re-INVITE request was sent -
>or maybe try some different offer (maybe it simply isn't
>possible to fall back to exactly the same SDP state as before
>the failed re-INVITE).
>
>So, the non-rollback alternative would work also for
>pre-conditions, assuming the UAC does the "manual fallback",
>and we wouldn't have the race-condition problem that Anders
>brought up.
>
>Also, wouldn't automatically "force" the SDP state back to
>it's previous state, in case it for whatever reason isn't
>possible for the UAC/UAS. We would give the users more choise
>on how to deal with the situation.
>
>Comments?
>
>Regards,
>
>Christer
>
>
>
>_______________________________________________
>Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP Use
>[e-mail] for questions on current sip
>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP