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

["Christer Holmberg" <christer.holmberg at ericsson.com>]

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?


Example with updated remote target:

re-INVITE ------------------->
UPDATE with new rem.target--->
<- 200 (UPDATE) --------------
<- 4xx (re-INVITE) -----------

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?

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