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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 08 May 2008 09:05:46 +0300

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2008 08:50:31 -0400

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 9 May 2008 09:18:38 +0200

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: 8. toukokuuta 2008 15:51
To: Gonzalo Camarillo
Cc: [email-masked]; sipping; Mary Barnes
Subject: Re: [Sipping] Liaison Statement on offer/answer procedures

	Thanks,
	Paul

> 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 list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] 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
[email-masked] for questions on current sip Use
[email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 15 May 2008 12:30:26 +0200

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
Sent: 9. toukokuuta 2008 10:19
To: Paul Kyzivat; Gonzalo Camarillo
Cc: [email-masked]; sipping; Mary Barnes
Subject: Re: [Sipping] Liaison Statement on offer/answer procedures

Hi,

Regards,

Christer 

-----Original Message-----

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 May 2008 08:34:41 -0400

> Does anyone have a problem with taking the-same-rule-applies-to-all-data

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.

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

> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 15 May 2008 15:20:40 +0200

Hi, 

>>Does anyone have a problem with taking
the-same-rule-applies-to-all-data approach?
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.

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.

>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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 May 2008 09:48:21 -0400

Christer,

Saying "you shouldn't do it" to changing contact address or media 
address ignores facts of life that may require doing it. This overlaps 
strongly with the session mobility discussion that is currently going on.

Specifically, if a UA is losing possession of its address, or 
connectivity via that address, then it will have to do *something*. If 
we are going to say that you shouldn't change the contact address in a 
dialog, and shouldn't change the media address in a media session, then 
we need to specify some alternative.

Clearly there are at least two distinct cases here:

- there is a desire to switch to a new address, but the old address
   can continue to be supported until and unless use of the new one
   can be established

- the possession of or connectivity via the old address is going
   away soon, or has already gone away. The UA is trying to preserve
   the session by switching to a viable address. There is a limited
   window of opportunity to achieve this.

So, I think we can't just consider this to be a perverse case to be 
specified, but which will never be used in practice. Rather, I think we 
need to demonstrate how what we specify can indeed work.

Regarding use cases: certainly we can start with the ones already out 
there. But at least we ought to identify which ones we are talking about 
so everyone will know. And we may need others, such as the one in your 
prior message.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 15 May 2008 21:00:26 +0200

Hi, 

>Saying "you shouldn't do it" to changing contact address or media
address ignores facts of life that may require doing 
>it. This overlaps strongly with the session mobility discussion that is
currently going on.

Please note that we are only discussing a very specific case here, when
UPDATEs/PRACKs are sent "within" a re-INVITE transaction. If someone
e.g. wants to update the target I guess it would normally be done by the
re-INVITE itself, NOT by an "intermediate" UPDATE.

>Specifically, if a UA is losing possession of its address, or
connectivity via that address, then it will have to do 
>*something*. If we are going to say that you shouldn't change the
contact address in a dialog, and shouldn't change the 
>media address in a media session, then we need to specify some
alternative.

Again, I am only talking about "updating" transactions which take place
between the re-INVITE request and final response.

If someone wants to update the target, or do major media changes, it
should be done by the re-INVITE itself, or an UPDATE which is not sent
"within" an ongoing re-INVITE transaction. I am pretty sure that is how
most implementations would do it today also.

>   window of opportunity to achieve this.

Sure, but again: do it when the re-INVITE is finished. And, if you
really can't wait until then, do it before, but if the re-INVITE fails
you then need to know what the state is supposed to be - no matter
whether you are able to fall back to that state or not.

Are there even implementations out there that send requests (at least
for non-precondition purposes) between a re-INVITE request and
response???

Regards,

Christer

>So, I think we can't just consider this to be a perverse case to be
specified, but which will never be used in practice. 
>Rather, I think we need to demonstrate how what we specify can indeed
work.
>Regarding use cases: certainly we can start with the ones already out
there. But at least we ought to identify which ones 
>we are talking about so everyone will know. And we may need others,
such as the one in your prior message.

	Thanks,
	Paul

> can easily get you into a situation where you can no longer 
> communicate to update the session. So I think the detailed
> 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.
> 

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

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 May 2008 21:19:16 +0100

Paul,

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 15 May 2008 14:48
> To: Christer Holmberg
> Cc: sipping List
> *something*. If 
[JRE] So if the contact address changes and we successfully conclude the
UPDATE transaction, and then the old contact address disappears, it is
likely that the Via list on the re-INVITE request will have become
invalidated too, so the final response will not reach the UAC. Correct?

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 16 May 2008 12:37:41 +0200

Hi John,

>invalidated too, so the final response will not reach the UAC. Correct?

I would say so. And, that is of course true no matter what resposne is sent to the re-INVITE.

So, eventhough your case is not directly related to the problem we are discussing, I think it shows one thing: do not update the target while you have other ongoing transactions.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 May 2008 08:38:48 -0400

John,

This is a good point.

It does expose a potentially long window when address changes are 
problematic. I guess if a quick address change is necessary then the 
INVITE, or reINVITE, can be CANCELed.

IMO this is starting to identify an area that could stand to have more 
specification. I guess this sounds like a best practices draft, but its 
still a little fuzzy to me. And I am far from clear whether this is 
tightly connected to the o/a rollback issue.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 16 May 2008 20:05:11 +0200

Hi,
 
I do NOT think John's case is connected to the rollback issue.
 
The rollback issue is: what happens to data that has been updated between the re-INVITE request and failure response? It of course included the target, but is not related to where responses are sent.
 
Responses are, afaik, always sent to where the request came from, so if one updates the local target he has to make sure that he listens to the "old" port if there are ongoing transactions.
 
Regards,
 
Christer

________________________________

Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: pe 16.5.2008 14:38
Vastaanottaja: Elwell, John
Kopio: Christer Holmberg; sipping List
Aihe: Re: [Sipping] Liaison Statement on offer/answer procedures

John,

This is a good point.

        Thanks,
        Paul