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

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

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: [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