[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Liaison Statement on offer/answer procedures
Hi,
>>When thinking about which alternative is the best, I think it's also
good to keep the following in mind:
>>
>>It is not only the SDP that may be "updated" by the "intermediate"
>>transactions. For example, I guess the remote target could also be
>>updated (see example below). So, what happens to that if the re-INVITE
>>then fails?
>>
>>So, whatever alternative we go for, I think that we should apply the
>>same rule to whatever data (SDP, remote target etc) has been updated
>>between the re-INVITE request and error response. Otherwise we will
>>really create a mess with confusion and interop problems.
>
>>Does anyone have a problem with taking
the-same-rule-applies-to-all-data approach?
>
>I agree that more state is in play that just the offer and answer.
>Its not entirely clear to me if they should be treated the same or not.
>Changing the contact address is especially messy since getting it wrong
can easily get you into a situation where you can no longer communicate
to update the session. So I think the detailed
>process of updating the contact address, including the error cases,
ought to be studied. Maybe it will turn out to be 1:1 with o/a state,
and maybe not.
I think that one should avoid doing these kind of updates, because no
matter what we decide I am sure there will be problems. But, I still
think we need to have a rule saying what happens with updated data in
this case.
>To provoke the study, perhaps we need to develop a set of use cases.
The one below is a start.
Well, I am not sure we need to do that. I think the target- and the
offer/answer use-cases.
There are of course also cases where a rollback is not possible. Assume
you include a message body in the UPDATE with some application control
message. That will be executed by the receiver when received, and it may
not be possible to un-execute it when the re-INVITE fails.
>>Example with updated remote target:
>>
>>re-INVITE ------------------->
>>UPDATE with new rem.target--->
>><- 200 (UPDATE) --------------
>><- 4xx (re-INVITE) -----------
>
>In the above, I gather that the UPDATE carries no SDP, right? So the
intent of sending it is independent of the reINVITE?
The UPDATE may contain SDP, but the purpose of the example was to show
that the same kind of problem exists for the remote target.
>>What happens to the new remote target? Is it kept, or is there a
fallback to whatever remote target was used before the UPDATE was sent?
>
>Well, if the point of sending it was because the old address was
becoming (or had become) non-viable, then rolling it back wouldn't be
helpful.
>
>Of course the same can be true of the media addresses in an o/a.
Exactly, so therefor one should avoid doing it. But, I still think we
need to have a rule saying what happens with the data IF it happens. If
a rollback is then not possible, I guess one has to try again, or
release the session.
3261 today says that there is a rollback if the re-INVITE fails, but one
could of course say that it doesn't take this intermediate transactions
into consideration.
Regards,
Christer
> Regards,
>
> Christer
>
>
>
>
>
>
> -----Original Message-----
> From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
> Behalf Of Christer Holmberg
> Sent: 9. toukokuuta 2008 10:19
> To: Paul Kyzivat; Gonzalo Camarillo
> Cc: mmusic-chairs at tools.ietf.org; sipping; Mary Barnes
> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>
>
> Hi,
>
> I agree with Paul. We need to choose *some* solution. So, I think it
> would be good that anyone who has a preference indicates that.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: 8. toukokuuta 2008 15:51
> To: Gonzalo Camarillo
> Cc: mmusic-chairs at tools.ietf.org; sipping; Mary Barnes
> Subject: Re: [Sipping] Liaison Statement on offer/answer procedures
>
> I agree that sipping is the right place for the work, and that it
> ought to be done, eventually. It hasn't seemed like especially
> pressing, but apparently 3gpp thinks otherwise.
>
> I agree that, at least on the surface, it is less important which
> solution is chosen than it is that *some* solution be chosen. But
> there are pros and cons to the two obvious approaches, so it is best
> to do more than just flip a coin.
>
> Thanks,
> Paul
>
> Gonzalo Camarillo wrote:
>> Folks,
>>
>> the SIPPING WG has received the following LS from 3GPP:
>>
>> https://datatracker.ietf.org/liaison/444/
>>
>> We have talked to the MMUSIC chairs (MMUSIC was in the cc: of this
>> LS)
>
>> and they are OK with working on this LS in SIPPING. In any case, we
>> will send our answer to the MMUSIC folks for comments before getting
>> back to 3GPP.
>>
>> This LS has to do with the offer/answer method, which was developed
>> by
>
>> MMUSIC, but is also related to the SIP machinery associated to
>> offer/answer (i.e., rejected re-INVITEs). That is why we consider
>> SIPPING the right place to discuss it.
>>
>> Comments on this LS are appreciated.
>>
>> Thanks,
>>
>> Gonzalo
>> SIPPING co-chair
>> _______________________________________________
>> 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
>
_______________________________________________
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