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

[Paul Kyzivat <[e-mail]>]

Christer Holmberg wrote:
> 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.

To provoke the study, perhaps we need to develop a set of use cases. The 
one below is a start.

> 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?

> 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.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
> 
>  
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Christer Holmberg
> Sent: 9. toukokuuta 2008 10:19
> To: Paul Kyzivat; Gonzalo Camarillo
> Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> Sent: 8. toukokuuta 2008 15:51
> To: Gonzalo Camarillo
> Cc: [e-mail]; 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 
>> [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
> _______________________________________________
> 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