Subject: [sipcore] New revision of the re-INVITE handling draft

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 06 Jul 2009 16:52:27 +0300

Folks,

[as individual]

I have just submitted a new revision of the re-INVITE handling draft. 
The last revision of this draft was presented and widely discussed in 
the SIPPING WG:

http://www.ietf.org/internet-drafts/draft-camarillo-sipcore-reinvite-00.txt

This draft documents the agreement among folks involved in the (endless) 
"rollback" discussions. Comments are welcome.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jul 2009 19:37:22 -0400

Gonzalo,

Thanks for doing this work! I do have some comments:

Section 3/Figure 1

The figure shows a 6xx response.
The text says that the UAS wants to reject the new offer.

A UAS would probably not use a 6xx response to reject media.
(I guess it might use 606, but 488 would be more appropriate.)
In fact, it probably would not reject the request at all, but rather 
would just refuse the added media stream.

The point being made doesn't require that the response be 6xx or that it 
be with the purpose of refusing the media. So I think what is needed 
here is to find a plausible example to make the point.

A good one for the purpose here might be a 488 to reject the media, or a 
  401 response as another sort of reason for rejecting the whole thing 
but wanting to preserve what there is.

Section 5:

>    A change to the session state is considered to have been executed
>    when the new media parameters are being used.  Therefore, a change to
>    a stream subject to preconditions [RFC4032] is considered to have
>    been executed when the new media parameters start being used; not
>    when the preconditions for the stream are met.  Unsurprisingly, the
>    UAS considers the new parameters to be in use when it actually starts
>    using them. 

I'm not entirely following this. I think there may be an assumption here 
that the UAC is the offerer and the UAS the answerer. I'm guessing you 
are saying that the answerer considers the new parameters to be in use 
when it actually starts using them.

Since this section is about the UAS (for the reinvite), this point is 
probably that when the UAS is also the answerer it can decide when the 
new media is in use based on when it starts using them.

But what happens when the UAS is the offerer? In that case I think it 
must assume the media is in use as soon as it is offered. But maybe that 
isn't always the case with preconditions. I don't think it can wait till 
it receives media, because media may be in flight when it makes its 
decision.

>    As described in Section 8.3.1 of RFC 3264 [RFC3264], the
>    UAC considers the new parameters to be in use when media is received
>    in the new port, which should be interpreted as follows:
> 
>       Received, in this case, means that the media is passed to a media
>       sink.  This means that if there is a playout buffer, the agent
>       would continue to listen on the old port until the media on the
>       new port reached the top of the playout buffer.  At that time, it
>       MAY cease listening for media on the old port.

I don't know what the above has to do with the behavior of the UAS.

> 9.  Clarifications on Target Refresh Requests
> 
>    On receiving a target refresh request with an updated remote target,
>    a UAS updates the remote target of the dialog immediately.  This
>    update represents the execution of a state change.  Therefore,
>    following the rules in Section 5, UASs always return 2xx responses to
>    target refresh requests that update the remote target.

This does not address cases where the UAS cannot accept the change with 
a 200. Some cases that fall into this category are:

- request includes a Require of an unsupported option (e.g. 100rel)
- request cannot be authorized
- server overload
- precondition failure

In any case, if no state changes have been made prior to the request 
with a target change, then there is no issue with rejecting the target 
refresh if need be.

The issue with target refresh is that the UA sending it may have an 
urgent need for it to be accepted, since it may not be able to 
communicate on its old address(es) any longer. And if that is the case 
it may also have an urgent need to change its media addresses as well 
for the same reason. That would be motivation for doing both at once.

If a reINVITE includes a target change, then its very difficult to know 
when the UAC must begin using it. So I think the UAS must assume it must 
be considered in use immediately. Hence it should *try* to avoid 
rejecting the request, even if it must reject all the media in the 
request. But there is still a possibility that it will have to reject 
due to authorization, overload, etc. If that is done right away its no 
different than any request rejected before any changes have been made.

A difficult case is where a reINVITE has been initiated, and has not 
completed. (Perhaps its ringing.) Then the UAC loses its IP address or 
IP connectivity and needs to make a target change. So it sends an UPDATE 
with the target change. What it should probably do in that case is *not* 
include an offer in the UPDATE. Then it can't be rejected for o/a 
reasons. Once that is done it can continue the o/a process, updating its 
media addresses when it has the chance. Once the UAC target has changed, 
the UAS should not fail the INVITE. If need be it should reject all the 
media in order to avoid that.

Another difficult case if if a reINVITE has been initiated and the UAS 
finds it needs to change its address. Similar considerations to above 
seem to apply.

Frankly, this is all very nasty, and those in this situation may have 
few options for what do do. It feels deserving of its own treatment. 
Namely a whole call flow document with various use cases where target 
change is required. Probably a BCP.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 7 Jul 2009 14:05:14 +0800

Hi,

Paul's words are alway constructive. And I just want to have a further 
talk about two parts of the Comments:

1. The feasibility of the way in the draft.

2. BCP and standard.

more inlines.

Thanks.

Gao

> different than any request rejected before any changes have been made.

[Gao] O/A exchange can not be processed in dialog/transaction(including 
INVITE and UPDATE) which is rejected 
due to authorization, overload. So, there are not the cases.

But for cautel, we need to demonstrate that there is no case/need to send 
error code(non-2xx) after O/A exchange. We can deduce as:
Three precondition(IMO, satisfied):
1. O/A exchange is in application level which is upon the sip level. And 
before the application level's processing, sip level should get ready. 
2. There are only two soure of error: application level itself and sip 
level. 
3. This draft talked about the way of avoiding sending error code(non-2xx) 
for application level's reason, such as rejecting media/media stream. 
Deduction:
Then the remaining part is demonstrating there is no case/need to send 
error semantics message(non-2xx/Cancel) for sip level's reason after O/A 
exchange.

If the deduction can be proved to be true, then the way in the draft is 
feasible.

> change is required. Probably a BCP.

[Gao] I am agreed that BCP(showing what is better) is needful, but not 
enough. For example, it is a hard work to make our IMS/AS system 
interworking with different UEs(SIP) which has different points of view 
for session state after un-successful Re-INVITE.

And absence of the standard(showing what is right) for session state would 
making equipment-interworking indeterminably.

>    Paul

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 10 Jul 2009 15:44:05 +0900

Hi,

I have some comments.

RFC3261 describe about the atomic process.

8 General User Agent Behavior
 8.2 UAS Behavior
   Note that request processing is atomic.  If a request is accepted,
   all state changes associated with it MUST be performed.  If it is
   rejected, all state changes MUST NOT be performed.

12 Dialogs
 12.2 Requests within a Dialog
 12.2.2 UAS Behavior
   Requests sent within a dialog, as any other requests, are atomic.  If
   a particular request is accepted by the UAS, all the state changes
   associated with it are performed.  If the request is rejected, none
   of the state changes are performed.

14 Modifying an Existing Session
 14.1 UAC Behavior
   If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been issued.

above rule work fine for re-INVITE and PRACK. but I think that UPDATE
and precondition procedure was considered insufficiently about an error
response to a re-INVITE.

if all changes executed by UPDATE transactions are excluded from the
rollback, are there any problems?

That is,
                 
  |   INVITE     |                  |              |
  |------------->|                  |              |
  |   183        |                  |              |
  |<-------------|                  |              |
  |   PRACK      |                  |              |
  |------------->|                  |              |
  |   200(PRACK) |                  |              |
  |<-------------| is identical to  |              |
  |   UPDATE     |                  |   UPDATE     |
  |------------->|                  |------------->|
  |   200(UPDATE)|                  |   200(UPDATE)|
  |<-------------|                  |<-------------|
  |   488(INVITE)|                  |              |
  |<-------------|                  |              |
  |   ACK        |                  |              |
  |------------->|                  |              |

This updates RFC3311.

But at this point, I have one doubt.
May precondition procedure be started by UPDATE?

>4.  Problems with Error Responses and Already-executed Changes
>   Using an error response to undo already executed changes presents an
>   additional problem.  Section 4 of [RFC3264] specifies rules to avoid
>   glare situations (i.e., to avoid offer/answer collisions in race
>   conditions).  Even when both UAs generate an offer at the same time,
>   there are rules to determine which one should be processed first.
>   However, there are no rules to avoid a collision between an offer in
>   an UPDATE request and an error response for a re-INVITE.  Since both
>   the UPDATE request and the error response would request changes, it
>   would not be clear which changes would need to be executed first.
>   This is yet another reason why UASs should not use error responses to
>   undo already-executed changes.

I think glare situations occur in three cases.

1.
 | UPDATE       488(reINVITE) |
 |---------\   /--------------|
 |          \ /       ACK     |
 |           X       -------->|
 |          / \               |
 |<--------/   \------------->|
 |                            |
 |                 200(UPDATE)|
 |<---------------------------|
 |                            |
                              
2.
 | UPDATE                     |
 |--------------------------->|
 |                200(UPDATE) |
 |             /--------------|
 |            /               |
 |           /  488(reINVITE) |
 |<---------/-----------------|
 |         /                  |
 |<-------/                   |
 |                    ACK     |
 |                   -------->|
 |                            |
                              
3.
 |               488(reINVITE)|
 |             /--------------|
 |            /       ACK     |
 |           /       -------->|
 |          /                 |
 |         /           UPDATE |
 |<-------/-------------------|
 |       /  200(UPDATE)       |
 |------/-------------------->|
 |     /                      |
 |<---/                       |
 |                            

>6.  UAC Behavior
>   In order to cope with this type of UAS, a UAC that receives an error
>   response to a re-INVITE for which changes have been already executed
>   SHOULD generate a new re-INVITE or UPDATE request in order to make
>   sure that both UAs have a common view of the state of the session.

If all changes are the results of only re-INVITE and PRARK, I think
new UPDATE(or re-INVITE) request is not necessary.

Regards,
Shinji

Paul Kyzivat <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jul 2009 09:27:05 -0400

> May precondition procedure be started by UPDATE?

IMO yes it may. But perhaps it SHOULD NOT ???

I think it has always been possible to initiate an in-dialog o/a 
exchange, with or without preconditions, using UPDATE rather than reINVITE.

I guess it would also be possible to start an INVITE/reINVITE without 
preconditions, and then initiate the use of preconditions with an 
UPDATE. But I can't think of any good reason why you would want to do that.

AFAIK there are only a couple of places where UPDATE is needed, or 
preferable alternatives:

- its needed by UAC for 2nd and subsequent rounds of O/A exchange
   within an INVITE.

- its good for a dialog refresh/target refresh when you *don't*
   want to do a new O/A.

Other uses can be accomplished other ways.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 13 Jul 2009 19:49:15 +0900

Hi,

comment inline.

Regards,
Shinji

>Thanks for doing this work! I do have some comments:

<snip>

>media in order to avoid that.

At this point, IP Address of the UAC has be changed, so the
responce of the reINVITE request could probably not be returned
to the UAC. And then reINVITE client transaction would return
a timeout. Rather it would be better to CANCEL it.

Altogether UPDATE transaction SHOULD be excluded from the
rollback, I think now.

---

From: [email-masked]
Date: Tue, 14 Jul 2009 08:15:35 +0800

Hi Shinji,

By RFC3311, the target refresh UPDATE can refresh the ongoing Re-INVITE, 
as below: 

UPDATE is a target refresh request. As specified in RFC 3261 [1],
   this means that it can update the remote target of a dialog. If a UA
   uses an UPDATE request or response to modify the remote target while
   an INVITE transaction is in progress, and it is a UAS for that INVITE
   transaction, it MUST place the same value into the Contact header
   field of the 2xx to the INVITE that it placed into the UPDATE request
   or response.

And then, we can get the correct session state by the way proposed in 
draft-camarillo-sipcore-reinvite-00. 

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 14 Jul 2009 11:33:10 +0900

Hi Gao,

Do you mean that the session state of the UPDATE transaction is NOT
excluded from the rollback, but the dialog state(ie remote target)
is excluded from the rollback?

[email-masked]
>   field of the 2xx to the INVITE that it placed into the UPDATE request

the above statement means that the 2xx to the INVITE include the same
Contact header of the UPDATE request or response. But UPDATE does not
modify the Via header of 2xx.

Regards,
Shinji

---

From: [email-masked]
Date: Tue, 14 Jul 2009 11:31:39 +0800

Hi Shinji,

Target fresh:
One target fresh is in just one sip transaction, not like session 
modification can overlap more than one sip transaction(such as 
precondition).
So, even the ongoing INVITE/Re-INVITE has target fresh, the target fresh 
in the UPDATE is a whole new one. As it is a whole new one, not part 
of the original one, so the target fresh in the UPDATE must not 
*rollback*.

Session modification:
When the O/A in UPDATE/200OK is part of the one triggered by 
INVITE/Re-INVITE, it is NOT excluded from the rollback. But when the O/A 
in 
UPDATE/200OK is a whole new one, IMO, it should excluded from the 
rollback.

BTW,
A standard regulation is really needed to end the very long session state 
discussion.

And as we should has a detailed classification of which O/A is part of the 
one triggered by INVITE/Re-INVITE and which is not, if we choose this way 
to 
solve the session state problm, now I support 
draft-camarillo-sipcore-reinvite-00. I'd like to concentrate on this 
solution.(I do not mean any restrict on any talking around my original 
proposal :))

Thanks.

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

OKUMURA Shinji <[email-masked]> 
2009-07-14 10:33

收件人
SIPCORE <[email-masked]>
抄送
[email-masked]
主题
Re: [sipcore] New revision of the re-INVITE handling draft

Hi Gao,

[email-masked]

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 14 Jul 2009 15:04:30 +0900

Hi Paul,

>>rollback, 

and if it is precondition case, both UAs need to start new O/A
with precondition. At that time, which should UA send new UPDATE
or new reINVITE ?

Because user confirmation for the rollback is not necessary,
I think reINVITE is not necessary. but I'm not sure.

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jul 2009 11:04:35 -0400

There is a difficult problem when the UAC has an urgent need to change
the target and an INVITE is in progress: the routing of responses to the
original INVITE, since they are governed by the Via headers of the
INVITE, not the target.

Perhaps that means that if you have an urgent need to change your
address while you have an incomplete INVITE outstanding, you should
CANCEL the INVITE and send a new one with the target refresh.

OTOH, if the UAS finds itself with that problem it can just initiate a
target refresh within the dialog. And in that case, if the INVITE
subsequently fails you wouldn't want the target change to be rolled back.

	Thanks,
	Paul

[email-masked] wrote:
> in the UPDATE is a whole new one. *As it is a whole new one, not part *
> *of the original one, so the target fresh in the UPDATE must not 
> *rollback*.*
> 
> Session modification:
> INVITE/Re-INVITE, it is NOT excluded from the rollback. But when the O/A in
> UPDATE/200OK is a whole new one, IMO, it should excluded from the rollback.
> 
> BTW,
> A standard regulation is really needed to end the very long session 
> state discussion.
> 
> And as we should has a detailed classification of which O/A is part of 
> the one triggered by INVITE/Re-INVITE and which is not, if we choose 
> this way to
> *OKUMURA Shinji <[email-masked]>*
> 
> 2009-07-14 10:33
> 
> 	
> 收件人
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 Jul 2009 12:55:48 +0300

Hi Paul,

thanks for your comments. Answers inline:

> but wanting to preserve what there is.

yes, I agree that a 488 response would be more appropriate. I will 
change that in the draft.

> it receives media, because media may be in flight when it makes its 

yes, the draft assumes that the UAS is the answerer because that was the 
use case being discussed originally. However, you are right that we 
should also cover the case where the UAS is the offerer. I will look 
into it and add text about it in the draft.

> I don't know what the above has to do with the behavior of the UAS.

The UAC needs to know when the new parameters are in use in order to 
implement the normative behavior in Section 6:

    ... a UAC that receives an error response to a re-INVITE for which
    changes have been already executed ...

In any case, I will clarify all this when I write the text about the UAS 
being the offerer because this type of behavior has to do with being the 
offerer or the answerer, not the UAC or the UAS.

>> 9.  Clarifications on Target Refresh Requests

the current text is a straw man that puts target refreshes in the same 
category as any other change. The other option we talked about in the 
past was to special case them so that they are treated differently. You 
seem to like the latter option better. What do you think about the 
following text?

<section title="Clarification on the Atomicity of Target Refresh Requests"
anchor="sec-atom">
<t>
The remote target of a dialog is a special type of state information
because of its essential role in the exchange of SIP messages between
UAs in a dialog. A UA involved in a dialog receives the remote target
of the dialog from the remote UA. The UA uses the remote target to
send SIP requests to the remote UA.
</t>
<t>
The remote target is a piece of state information that is not meant to
be negotiated. When a UAC changes its address, the UAC simply
communicates its new address to the UAS in order to remain reachable
by the UAS. As described in <xref target="sec-back-atom"/>, a UAS
starts using the new remote target as soon as the target refresh
request is received, regardless of the response the UAS generates to
that request. That is, even if the UAS generates an error response to
the target refresh request, the UAS needs to update the dialog's
remote target URI.
</t>
<t>
The fact that a target refresh request updates the remote target
regardless of the response it triggers implies that target refresh
requests are not atomic. That is, an error response to a target
refresh request will keep all changes associated to the request from
being performed except for the refresh of the remote target, which
will be performed anyway.
</t>
</section>

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jul 2009 10:43:55 +0300

Hi,

>   In order to make "Already-executed Changes" clear, the draft should 
> state 
> when UAS/UAC start to listen on the new port, and when UAS/UAC use 
> new media parameters. It's essential for users to find the right state, I 
> think.
> 

yes, it is essential. In any case, the draft will not define anything
new in this respect. We will use the definition in RFC 3264 and clarify
it if needed.

Thanks for your comments,

Gonzalo

---

From: [email-masked]
Date: Thu, 23 Jul 2009 15:30:20 +0800

Hi，

There may be three choices, when 200OK is sent,or offer/answer pair is 
finish,
or preconditions are met.

IMO UAS should start to listen on the new port when 200OK is sent, 
when user makes his/her decision to accept the re-Invite.
But I'm not sure about the UAC, should it start to use the new parameters 
after receive 200OK?

Regards.
Eric

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2009 09:12:44 -0400

Gonzalo,

I agree with all you say below, except at the very end about target refresh.

If target refreshes are to be accepted even if the request fails, then 
it is possible to hijack a session even if authentication is being used 
for signaling.

IMO a target refresh must be ignored in at least *some* cases when the 
request is rejected. We could enumerate these cases individually, or 
simply state that it will only be accepted if the request is accepted. 
(In case of reINVITE, that would be if it was accepted sufficiently to 
return a 2xx or a 1xx.)

This will encourage using a *simple* request to do an essential target 
refresh, rather than a complex one that has a chance of failing. Perhaps 
it won't work in all cases, but such is life.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
>> The point being made doesn't require that the response be 6xx or that 
>> it be with the purpose of refusing the media. So I think what is 
>> needed here is to find a plausible example to make the point.
>>
>> A good one for the purpose here might be a 488 to reject the media, or 
>> a  401 response as another sort of reason for rejecting the whole 
>> thing but wanting to preserve what there is.
> 
>> I'm not entirely following this. I think there may be an assumption 
>> here that the UAC is the offerer and the UAS the answerer. I'm 
>> guessing you are saying that the answerer considers the new parameters 
>> to be in use when it actually starts using them.
>>
>> must assume the media is in use as soon as it is offered. But maybe 
>> that isn't always the case with preconditions. I don't think it can 
>> wait till it receives media, because media may be in flight when it 
>> makes its decision.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jul 2009 16:35:17 +0300

Hi Paul,

 > refresh, rather than a complex one that has a chance of failing.

Yes, I agree with you. I think we can get what you are looking for by 
keeping the text that is currently in the draft (i.e., re-INVITEs remain 
atomic and an error response rolls everything back, including the target 
refresh), by adding a description of why piggybacking other changes in a 
target refresh request is a bad idea (the new text would include a 
discussion on the Via problem and on legacy UASs responding with an 
error response even if changes have been executed), and by discouraging 
the use of re-INVITEs that update the target and perform other changes 
at the same time (we probably need to go as far as to say that one 
SHOULD NOT do it).

I agree with you that encouraging the use of "simple" requests will be 
better than specifying complex behavior just to cover corner cases.

Thanks,

Gonzalo

Paul Kyzivat wrote:
>>> A good one for the purpose here might be a 488 to reject the media, 
>>> or a  401 response as another sort of reason for rejecting the whole 
>>> guessing you are saying that the answerer considers the new 
>>> parameters to be in use when it actually starts using them.
>>>
>>> probably that when the UAS is also the answerer it can decide when 
>>> the new media is in use based on when it starts using them.
>>>
>> yes, the draft assumes that the UAS is the answerer because that was 
>> the use case being discussed originally. However, you are right that 
>> we should also cover the case where the UAS is the offerer. I will 
>> look into it and add text about it in the draft.
>>
>>>
>> In any case, I will clarify all this when I write the text about the 
>> UAS being the offerer because this type of behavior has to do with 
>> being the offerer or the answerer, not the UAC or the UAS.
>>
>>
>> past was to special case them so that they are treated differently. 
>> You seem to like the latter option better. What do you think about the 
>> following text?
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2009 12:36:20 -0400

I'm don't know if we are on quite the same page yet.
Once accepted, I don't think a target refresh should be rolled back by 
anything.

A key use case might be:

I've started an reINVITE - one that might take awhile because it is 
trying to add media and the other end is alerting about that.

While that is in progress I lose my IP address and need to target 
refresh. So what do I do?

I think I send an UPDATE, which will be in the midst of the reINVITE 
transaction. I make it a simple one, in that it includes no o/a, its 
*just* a target refresh. Of course the Via for it has the new ip 
address. It *might* be rejected with 401. If so I may have to try again, 
but at least I have a chance of getting the response and trying again.

Now the reINVITE itself is going to fail, because the responses will be 
going to a non-functional address based on the Via for the reINVITE. 
What we *don't* want is for the failure of the reINVITE to roll back the 
target refresh. The UAC can try sending a CANCEL following the UPDATE. 
It can have the new address as its Via. But still the resulting 487 for 
the reINVITE will go to the wrong address. Eventually the UAC can send 
another reINVITE with the new target. Or the UAS can send a new reINVITE 
to the new target address.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
>> it is possible to hijack a session even if authentication is being 
>> used for signaling.
>>
>> Perhaps it won't work in all cases, but such is life.
>>
>>     Thanks,
>>     Paul
>>
>> Gonzalo Camarillo wrote:
>>> Hi Paul,
>>>
>>>> The point being made doesn't require that the response be 6xx or 
>>>> that it be with the purpose of refusing the media. So I think what 
>>>> is needed here is to find a plausible example to make the point.
>>>>
>>>> Since this section is about the UAS (for the reinvite), this point 
>>>> is probably that when the UAS is also the answerer it can decide 
>>>> when the new media is in use based on when it starts using them.
>>>>
>>>> But what happens when the UAS is the offerer? In that case I think 
>>>> it must assume the media is in use as soon as it is offered. But 
>>>> maybe that isn't always the case with preconditions. I don't think 
>>>> it can wait till it receives media, because media may be in flight 
>>>> when it makes its decision.
>>>
>>> the current text is a straw man that puts target refreshes in the 
>>> same category as any other change. The other option we talked about 
>>> in the past was to special case them so that they are treated 
>>> differently. You seem to like the latter option better. What do you 
>>> think about the following text?
>>>
>>>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 23 Jul 2009 12:51:27 -0400

In theory it is okay to say that each request should be atomic, i.e. UAC
should not request another operation on a request which is target
refresh request. But in order to minimize signaling and deployment of
legacy UA, it will continue to happen in practice. So having some kind
of BCP text in the draft is a good idea. But I agree with Paul, that
there should be a  list of error codes for which the target refresh is
not rolled back and others for which previous one remains in effect. We
have seen the issue many times, does 488 response to a re-Invite causes
target refresh to be applied or not. Having a list will go a long way in
clarifying such cases.

Thanks

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
>Sent: Thursday, July 23, 2009 7:05 PM
>To: Paul Kyzivat (pkyzivat)
>Cc: [email-masked]; SIPCORE
>Subject: Re: [sipcore] New revision of the re-INVITE handling draft
>
>Hi Paul,
>
> > This will encourage using a *simple* request to do an 
>essential target  > refresh, rather than a complex one that 
>has a chance of failing.
>
>Yes, I agree with you. I think we can get what you are looking 
>for by keeping the text that is currently in the draft (i.e., 
>re-INVITEs remain atomic and an error response rolls 
>everything back, including the target refresh), by adding a 
>description of why piggybacking other changes in a target 
>refresh request is a bad idea (the new text would include a 
>discussion on the Via problem and on legacy UASs responding 
>with an error response even if changes have been executed), 
>and by discouraging the use of re-INVITEs that update the 
>target and perform other changes at the same time (we probably 
>need to go as far as to say that one SHOULD NOT do it).
>
>I agree with you that encouraging the use of "simple" requests 
>will be better than specifying complex behavior just to cover 
>corner cases.
>
>Thanks,
>
>Gonzalo
>
>
>
>Paul Kyzivat wrote:
>> Gonzalo,
>> 
>>>> (I guess it might use 606, but 488 would be more appropriate.) In 
>>>> fact, it probably would not reject the request at all, but rather 
>>> in the past was to special case them so that they are 
>treated differently.
>>> You seem to like the latter option better. What do you think about 
>>> the following text?
>>>
>>>
>>> The remote target is a piece of state information that is not meant 
>>> to be negotiated. When a UAC changes its address, the UAC simply

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Jul 2009 14:33:37 +0200

Hi,

I am just re-booting after my summer vacation, and I have NOT been able
to read all e-mails in this thread yet. So, I appologize if something
has been discussed.

Regarding the proposal to not be able to reject a target update. If you
use Outbound, where you have created the NAT binding as part of the
registration, a target refresh can not be performed, because the
signalling wouldn't reach the client behind the NAT anymore. You would
need to perform a re-registration.

Now, we could of course say that a client using Outbound shall not
perform a target refresh in the first place. BUT, the same issue also
apply to other registration-based NAT traversal mechanisms - in some
cases the client behind the NAT may not even be aware of those.

So, if we want to say that one cannot reject a target refresh we need to
make sure we don't create a new cannot-reject-offer-in-PRACK type of
problem...

anything.
>I've started an reINVITE - one that might take awhile because it is
trying to add media and the other end is alerting 
>about that.
>I think I send an UPDATE, which will be in the midst of the reINVITE
transaction. I make it a simple one, in that it 
>includes no o/a, its *just* a target refresh.

In most cases, won't you use the same IP address for signalling and
media? So, if you've lost it you would need to re-negotiate the media
parameters also...

I think it would be much better for the UAC to first cancel the
re-INVITE, and then do the target refresh and re-start the o/a
transaction.

Performing target refreshes inside ongoing re-INVITEs are only going to
cause problems - especially if you are not able to receive responses etc
on the old address.

Regards,

Christer

> Hi Paul,
> 
>  > This will encourage using a *simple* request to do an essential 
> target  > refresh, rather than a complex one that has a chance of
failing.
> keeping the text that is currently in the draft (i.e., re-INVITEs 
> remain atomic and an error response rolls everything back, including 
> the target refresh), by adding a description of why piggybacking other

> changes in a target refresh request is a bad idea (the new text would 
> include a discussion on the Via problem and on legacy UASs responding 
> with an error response even if changes have been executed), and by 
> discouraging the use of re-INVITEs that update the target and perform 
> other changes at the same time (we probably need to go as far as to 
> say that one SHOULD NOT do it).
> 

>> If target refreshes are to be accepted even if the request fails, 
>> then it is possible to hijack a session even if authentication is 
>> being used for signaling.
>>
>> IMO a target refresh must be ignored in at least *some* cases when 
>> the request is rejected. We could enumerate these cases individually,

>> or simply state that it will only be accepted if the request is
accepted.
>> (In case of reINVITE, that would be if it was accepted sufficiently 
>> to return a 2xx or a 1xx.)
>>
>> This will encourage using a *simple* request to do an essential 
>> target refresh, rather than a complex one that has a chance of
failing.

>>>> or a  401 response as another sort of reason for rejecting the 
>>>> whole thing but wanting to preserve what there is.
>>>

>>> because of its essential role in the exchange of SIP messages 
>>> between UAs in a dialog. A UA involved in a dialog receives the 
>>> remote target of the dialog from the remote UA. The UA uses the 
>>> remote target to send SIP requests to the remote UA.
>>> </t>
>>> <t>

>>> that request. That is, even if the UAS generates an error response 
>>> to the target refresh request, the UAS needs to update the dialog's 
>>> remote target URI.
>>> </t>
>>> <t>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jul 2009 09:13:47 -0400

> make sure we don't create a new cannot-reject-offer-in-PRACK type of

First, I'm not saying you can't reject a target refresh.
Recommending you shouldn't reject it if you have alternatives is not the 
same. For instance if you have an authorization failure then you should 
definitely reject it.

> media? So, if you've lost it you would need to re-negotiate the media

Yes, you will probably need to renegotiate the media too. But that isn't 
quite as urgent. If need be it can wait until you have a working 
signaling path again.

> re-INVITE, and then do the target refresh and re-start the o/a

As I noted, if you have really lost your ip address, then while you can 
send the CANCEL, you won't get the final response to the reINVITE that 
was canceled. You can either send the CANCEL, wait the full timeout 
interval, then send a new target refresh, or you can send the target 
refresh first (so you know you have a working signaling path again), 
then send the CANCEL.

OTOH, if there is overlap in address availability (e.g. your renew of 
the lease on your IP address was rejected but hasn't yet expired) then 
it indeed would be prudent to wait for a quiescent state and then send 
the refresh.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 24 Jul 2009 15:30:00 +0200

Hi, 

>> I am just re-booting after my summer vacation, and I have NOT been 
>> able to read all e-mails in this thread yet. So, I appologize if 
>> something has been discussed.
>> 
>> Regarding the proposal to not be able to reject a target update. If 
>> you use Outbound, where you have created the NAT binding as part of 
>> the registration, a target refresh can not be performed, because the 

>> So, if we want to say that one cannot reject a target refresh we need

>> to make sure we don't create a new cannot-reject-offer-in-PRACK type 
>> of problem...
>

I wasn't directly arguing against you, just giving some general input :)

>Recommending you shouldn't reject it if you have alternatives is not
the same. For instance if you have an authorization >failure then you
should definitely reject it.

Yes.

So, just for me to catch up: the current proposal is that a failed
re-INVITE would not rollback a target refresh that has been sucessfully
performed (e.g. using UPDATE)?

>>> Once accepted, I don't think a target refresh should be rolled back 
>>> by anything.
>>> A key use case might be:
>>>
>>In most cases, won't you use the same IP address for signalling and
media? So, if you've lost it you would need to re-
>>negotiate the media parameters also...
>
>Yes, you will probably need to renegotiate the media too. But that
isn't quite as urgent. If need be it can wait until 
>you have a working signaling path again.

True.

But, if you are using ICE, or some other media plane procedures, those
won't work anymore.

>>I think it would be much better for the UAC to first cancel the
re-INVITE, and then do the target refresh and re-start 
>>the o/a transaction.
send the CANCEL, you won't get the final response 
>to the reINVITE that was canceled.

You won't get 18x responses, and final responses, either..

And, if you are still performing re-transmission of something which was
originally sent from the old address, can you switch those to the new
address just like that?

>OTOH, if there is overlap in address availability (e.g. your renew of
the lease on your IP address was rejected but 
>hasn't yet expired) then it indeed would be prudent to wait for a
quiescent state and then send the refresh.

If you can't use the old IP address anymore (e.g. because you lost it),
aren't you going to have to first do a re-registration in any case?
Trying to fix things with a target refresh - especially in the middle of
anohter negotiation procedure - is not going to work, I am pretty sure
of...

Regards,

Christer

> Performing target refreshes inside ongoing re-INVITEs are only going 
> to cause problems - especially if you are not able to receive 
> responses etc on the old address.

>>>>>>    when the preconditions for the stream are met.  
>>>>>> Unsurprisingly,
> the
>>>>>>    UAS considers the new parameters to be in use when it actually

>>>>>> starts

>>>>>>       Received, in this case, means that the media is passed to a

>>>>>> media

---

From: [email-masked]
Date: Sat, 25 Jul 2009 20:18:45 +0800

Hi,

I am at Stockholm now.

I once asked Paul about this IETF meeting. He said that he would be too 
busy to attend this time. It is a pity.

And as we know, there is a milestone for correction of RFC3261. And I 
think session state and dialog state correction are important parts of 
this correction.

And if we can notify the talk in the meeting in the maillist and collect 
viewpoint from the maillist on time, we can have a talk as if people 
concerning this topic are on the scene. And this can make the talk fast 
and effective.

If Gonzalo has time, he can be the proper person to take charge of this 
talk.

Thanks.

Gao

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2009-07-24 21:13

收件人
Christer Holmberg <[email-masked]>
抄送
[email-masked], SIPCORE <[email-masked]>, Gonzalo Camarillo 
<[email-masked]>
主题
Re: [sipcore] New revision of the re-INVITE handling draft

                 Thanks,
                 Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 26 Jul 2009 13:51:40 +0300

Hi Gao,

I do not see the need to have a face-to-face presentation on this topic
at this point. We already have an agreed and documented-in-a-draft
solution for the session state and will have a solution for the target
refresh stuff very soon as well (the discussions are already
converging). Let's finish this on the list.

Cheers,

Gonzalo

[email-masked] wrote:
> *Paul Kyzivat <[email-masked]>*

---

From: [email-masked]
Date: Sun, 26 Jul 2009 19:34:09 +0800

Hi Gonzalo,

OK.

Thank.

Gao

Gonzalo Camarillo <[email-masked]> 
2009-07-26 18:51

收件人
[email-masked]
抄送
Paul Kyzivat <[email-masked]>, Christer Holmberg 
<[email-masked]>, SIPCORE <[email-masked]>
主题
Re: 答复: Re: [sipcore] New revision of the re-INVITE handling draft

Hi Gao,

Cheers,

Gonzalo

> 7"<~HK:  [email-masked]
> 
> 2009-07-24 21:13
> 
> 
> JU<~HK
> 3-KM
> VwLb
able
>  > Regarding the proposal to not be able to reject a target update. If 
you
to
>  >> Once accepted, I don't think a target refresh should be rolled back 
by
to
Unsurprisingly,
>  >>>>>>       would continue to listen on the old port until the media 
on
> ZTE Information Security Notice: The information contained in this mail 
is solely property of the sender's organization. This mail communication 
is confidential. Recipients named above are obligated to maintain secrecy 
and are not permitted to disclose the contents of this communication to 
others.
> This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
originator of the message. Any views expressed in this message are those 
of the individual sender.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 27 Jul 2009 14:49:51 +0200

Hi,

it seems we can cover most cases with the following rules:

1) a reliable provisional response or a 2xx response to a target refresh 
confirms that the UAS has refreshed the target. This refresh is not 
rolled back under any circumstance (i.e., even if the target refresh was 
a re-INVITE that eventually failed or the target refresh was an UPDATE 
within a re-INVITE that eventually failed).

2) if the target refresh is rejected without any previous reliable 
provisional response, the target is not refreshed (this allows UASs to 
authenticate target refresh requests).

3) a reliable provisional response or a 2xx response to a target refresh 
request can refresh the target. Such a refresh is never rolled back 
either. (The UAS for the re-INVITE could of course also choose to send 
an UPDATE instead of refreshing the target in a response to the re-INVITE.)

We would also recommend UACs not to piggyback a target refresh with 
session changes in re-INVITEs that do not use 100rel because this would 
make it unnecessarily complicated for the UAS to accept the target 
refresh but to reject the session changes.

With respect to a UAC for a re-INVITE losing its IP address, the right 
thing to do would be to send an UPDATE to refresh the target, cancel the 
re-INVITE because the UAC would not be able to receive responses for it 
any longer, and initiate a new re-INVITE or UPDATE in order to get the 
media session in sync again.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>>> accepted. (In case of reINVITE, that would be if it was accepted 
>>> sufficiently to return a 2xx or a 1xx.)
>>>
>>> failing. Perhaps it won't work in all cases, but such is life.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> Gonzalo Camarillo wrote:
>>>> Hi Paul,
>>>>
>>>>> In fact, it probably would not reject the request at all, but 
>>>>> rather would just refuse the added media stream.
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jul 2009 09:39:02 -0400

> media session in sync again.

I'm fine with all of the above - its clear and precise. In the last 
paragraph, the order of events is important.

	Thanks,
	Paul

>> address. It *might* be rejected with 401. If so I may have to try 
>> again, but at least I have a chance of getting the response and trying 
>> again.
>>
>> Now the reINVITE itself is going to fail, because the responses will 
>> be going to a non-functional address based on the Via for the 
>> reINVITE. What we *don't* want is for the failure of the reINVITE to 
>> roll back the target refresh. The UAC can try sending a CANCEL 
>> following the UPDATE. It can have the new address as its Via. But 
>> still the resulting 487 for the reINVITE will go to the wrong address. 
>> Eventually the UAC can send another reINVITE with the new target. Or 
>> the UAS can send a new reINVITE to the new target address.
>>
>>     Thanks,
>>     Paul
>>
>> Gonzalo Camarillo wrote:
>>> Hi Paul,
>>>
>>> target
>>> the target refresh), by adding a description of why piggybacking 
>>> other changes in a target refresh request is a bad idea (the new text 
>>> would include a discussion on the Via problem and on legacy UASs 
>>> responding with an error response even if changes have been 
>>> executed), and by discouraging the use of re-INVITEs that update the 
>>> target and perform other changes at the same time (we probably need 
>>> to go as far as to say that one SHOULD NOT do it).
>>>
>>> I agree with you that encouraging the use of "simple" requests will 
>>> be better than specifying complex behavior just to cover corner cases.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>>
>>>
>>> Paul Kyzivat wrote:
>>>> Gonzalo,
>>>>
>>>> the request is rejected. We could enumerate these cases 
>>>> individually, or simply state that it will only be accepted if the 
>>>> request is accepted. (In case of reINVITE, that would be if it was 
>>>> accepted sufficiently to return a 2xx or a 1xx.)
>>>>
>>>>>> A good one for the purpose here might be a 488 to reject the 
>>>>>> media, or a  401 response as another sort of reason for rejecting 
>>>>>> the whole thing but wanting to preserve what there is.
>>>>>
>>>>>>> Unsurprisingly, the
>>>>>> I'm not entirely following this. I think there may be an 
>>>>>> assumption here that the UAC is the offerer and the UAS the 
>>>>>> answerer. I'm guessing you are saying that the answerer considers 
>>>>>> the new parameters to be in use when it actually starts using them.
>>>>>>
>>>>> yes, the draft assumes that the UAS is the answerer because that 
>>>>> was the use case being discussed originally. However, you are right 
>>>>> that we should also cover the case where the UAS is the offerer. I 
>>>>> will look into it and add text about it in the draft.
>>>>>
>>>>>>
>>>>> The UAC needs to know when the new parameters are in use in order 
>>>>> to implement the normative behavior in Section 6:
>>>>>
>>>>> In any case, I will clarify all this when I write the text about 
>>>>> the UAS being the offerer because this type of behavior has to do 
>>>>> with being the offerer or the answerer, not the UAC or the UAS.
>>>>>
>>>>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Jul 2009 16:01:34 +0200

Hi, 

>1) a reliable provisional response or a 2xx response to a target
refresh confirms that the UAS has refreshed the target. 
>This refresh is not rolled back under any circumstance (i.e., even if
the target refresh was a re-INVITE that eventually 
>failed or the target refresh was an UPDATE within a re-INVITE that
eventually failed).
>2) if the target refresh is rejected without any previous reliable
provisional response, the target is not refreshed 
>(this allows UASs to authenticate target refresh requests).
>
>3) a reliable provisional response or a 2xx response to a target
refresh request can refresh the target. Such a refresh 
>is never rolled back either. (The UAS for the re-INVITE could of course
also choose to send an UPDATE instead of 
>refreshing the target in a response to the re-INVITE.)
>
session changes in re-INVITEs that do not use 100rel 
>because this would make it unnecessarily complicated for the UAS to
accept the target refresh but to reject the session 
>changes.

In general I am ok with the rules, but we may need to think a little
about UNreliable provisional responses. 

For example, if a UAC sends an (re-)INVITE, and receives an UNreliable
18x, isn't there then an early dialog created in the UAC-to-UAS
direction, and the UAC can start sending in-dialog messages towards the
UAS at that point?

So, the question is: does an unreliable response update the remote
target, or where will the UAC send those in-dialog messages?

>With respect to a UAC for a re-INVITE losing its IP address, the right
thing to do would be to send an UPDATE to refresh >the target, cancel
the re-INVITE because the UAC would not be able to receive responses for
it any longer, and initiate a 
>new re-INVITE or UPDATE in order to get the media session in sync
again.

I think we need to say something about that there may be cases where a
re-registration is also needed.

Regards,

Christer

again.
> be going to a non-functional address based on the Via for the
reINVITE.
> What we *don't* want is for the failure of the reINVITE to roll back 
> the target refresh. The UAC can try sending a CANCEL following the
UPDATE.
> It can have the new address as its Via. But still the resulting 487 
> for the reINVITE will go to the wrong address. Eventually the UAC can 
> send another reINVITE with the new target. Or the UAS can send a new 
> reINVITE to the new target address.
> 
>     Thanks,
>     Paul
> 
> Gonzalo Camarillo wrote:
>> Hi Paul,
>>
failing.

>>>> The remote target of a dialog is a special type of state 
>>>> information because of its essential role in the exchange of SIP 
>>>> messages between UAs in a dialog. A UA involved in a dialog 
>>>> receives the remote target of the dialog from the remote UA. The UA

>>>> uses the remote target to send SIP requests to the remote UA.
>>>> </t>
>>>> <t>

>>>> communicates its new address to the UAS in order to remain 
>>>> reachable by the UAS. As described in <xref 
>>>> target="sec-back-atom"/>, a UAS starts using the new remote target 
>>>> as soon as the target refresh request is received, regardless of 
>>>> the response the UAS generates to that request. That is, even if 
>>>> the UAS generates an error response to the target refresh request, 
>>>> the UAS needs to update the dialog's remote target URI.
>>>> </t>
>>>> <t>
>>>> refresh request will keep all changes associated to the request 
>>>> from being performed except for the refresh of the remote target, 
>>>> which will be performed anyway.
>>>> </t>
>>>> </section>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>
>>

---

From: [email-masked]
Date: Tue, 28 Jul 2009 00:59:19 +0800

I am fine with the rules too.

Thanks.

Gao

2009-07-27 21:39

收件人
Gonzalo Camarillo <[email-masked]>
抄送
SIPCORE <[email-masked]>, [email-masked]
主题
Re: [sipcore] New revision of the re-INVITE handling draft

                 Thanks,
                 Paul

>>>>> because of its essential role in the exchange of SIP messages 
between
to
to

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 15:56:48 +0200

Hi Christer,

> target, or where will the UAC send those in-dialog messages?

In your example, the re-INVITE is a target refresh request. That means 
that the UAC can change its location. However, the UAC continues using 
the UAS's location to send requests... and the UAS's location cannot be 
changed with an unreliable response (only reliable responses can refresh 
the target; we may need to stress this point so that it is clear). 
Therefore, your example can be handled easily.

A more interesting example would be one where the UAC sends a re-INVITE 
updating the target (i.e., the UAC's location) and the UAS (which does 
not support reliable provisional responses) sends a request to the UAC 
using the new target.

I think we should add a rule that requests coming from the remote UA 
that use the new target confirm that the target has been refreshed.

> re-registration is also needed.

sure, we can mention this, although it is not directly related to the 
target refresh procedure... but I agree it will be a good idea to 
mention it in the draft.

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Jul 2009 16:17:51 +0200

Hi, 

>sure, we can mention this, although it is not directly related to the
target refresh procedure... but I agree it will be 
>a good idea to mention it in the draft.

In fact, I think the client will have to re-register very often. For
example, if the client has registered its previous IP address it needs
to re-register the new IP address. Otherwise it will not receive
incoming calls, since the registrar will forward those towards the old
address...

I do agree it is not directly relatd to target refresh, but IF we want
to have text about the case where the IP address is lost I think it is
important to mention.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 16:28:30 +0200

Hi,

OK, we seem to have reached agreement on how to proceed. I will revise 
the draft taking into account Paul's original comments and specifying 
the rules I proposed for target refresh together with the additions to 
address Christer's last comments.

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Jul 2009 16:35:50 +0200

Hi,

>>direction, and the UAC can start sending in-dialog messages towards 
>>the UAS at that point?
>> 
that the UAC can change its location. However, the 
>UAC continues using the UAS's location to send requests... and the
UAS's location cannot be changed with an unreliable 
>response (only reliable responses can refresh the target; we may need
to stress this point so that it is clear). 

I would be happy if that would be the case, but we need to discuss
whether it really is the case.

As I said, for an initial INVITE I believe an unreliable response can
create an early dialog in the UAC-to-UAS direction, which means that if
the unreliable response contains a remote target (Contact header) it
will be used by the UAC for in-dialog messages.

So, unless I am wrong we would say that it is possible to provide the
remote target unreliably for an initial INVITE, but it is not possible
to update it unreliably for a re-INVITE.

>A more interesting example would be one where the UAC sends a re-INVITE
updating the target (i.e., the UAC's location) 
>and the UAS (which does not support reliable provisional responses)
sends a request to the UAC using the new target.
>I think we should add a rule that requests coming from the remote UA
that use the new target confirm that the target has >been refreshed.

Yes.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 16:38:16 +0200

Hi Christer,

> to update it unreliably for a re-INVITE.

yes, that is what I said in my previous email. We are in agreement. An 
unreliable response cannot refresh a target.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 10:54:56 -0400

> Therefore, your example can be handled easily.

Agree.

> that use the new target confirm that the target has been refreshed.

Pragmatically this makes sense.
Its a little like a NOTIFY establishing a new dialog.

But it can only be a *successful* request. If the request is rejected 
(e.g. 401) then it is not a confirmation.

> target refresh procedure... but I agree it will be a good idea to 

This is a sensitive area. IETF has never embraced the linkage of 
REGISTER to ongoing sessions. I don't think this is the time.

That is really an IMS convention. I'd be inclined to leave it to them to 
address in their specs.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 17:01:59 +0200

Hi,

> (e.g. 401) then it is not a confirmation.

if the UAS wants to authenticate the re-INVITE, it would return a 401 
right away. The UAS only refreshes the remote target and, thus, sends a 
request to the new location of the UAC, if it decides that the re-INVITE 
was authenticated.

Of course, the re-INVITE could be rejected later because of a different 
reason (e.g., a 488). That would not rollback the target refresh, as we 
have agreed.

> That is really an IMS convention. I'd be inclined to leave it to them to 

That is why I said that it is not directly related to the target refresh 
issue. When talking about a user agent that loses its IP address, we can 
mention that it may want to re-register, but I intend to simply mention 
it very briefly without any normative behavior.

I am happy either way (talking or not taking about it), but I fully 
agree that we do not want to specify anything new in this area.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 11:22:55 -0400

> unreliable response cannot refresh a target.

Hmm...

That means that the UAC of a reINVITE, when it receives an unreliable 
response with a new target, MUST NOT refresh the target at that time?

That will certainly make the code inconsistent with what is implemented 
for the initial INVITE. And probably break a lot of implementations.

I'm not certain one way or the other on this. My inclination is that it 
can refresh the target, but the UAS won't know if it has.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 11:25:01 -0400

Gonzalo Camarillo wrote:
>> That is really an IMS convention. I'd be inclined to leave it to them 
>> to address in their specs.
> 

OK. I'm fine with *that*. It may also want to refresh any other dialogs 
it has established, such as subscriptions.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Jul 2009 17:25:46 +0200

Hi, 

>>This is a sensitive area. IETF has never embraced the linkage of
REGISTER to ongoing sessions. I don't think this is the >>time.

If you loose your address, and you have registered your old address, you
need to register your new address in order to receive incoming calls
(and to make things like outbound to work). I see nothing IMS specific
in that...

But, I agree with you that we should not start specifying new procedures
which are not directly related to target refresh. I only ask for a
statement which indicates that a re-registration may be needed in the
case of IP address loss. 

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 17:27:29 +0200

Hi,

answers inline:

> can refresh the target, but the UAS won't know if it has.

yes, that is the problem. If we let unreliable responses change things, 
the UAS is not aware if the UAC received them or not. So, if the UAS 
later sends a 4xx for the re-INVITE, it does not know if the UAC has 
refreshed the target (if the UAC received the response) or not (if the 
UAC did not receive it). We would be creating a mechanism that gets UAs 
out of sync.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 17:29:18 +0200

Hi,

> it has established, such as subscriptions.

sure, I will mention that as well. Again, as a general consideration so 
that implementors understand the scenario.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 11:38:59 -0400

Gonzalo Camarillo wrote:
>>> yes, that is what I said in my previous email. We are in agreement. 
>>> An unreliable response cannot refresh a target.
>>
>> Hmm...
>>
>> That will certainly make the code inconsistent with what is 
>> implemented for the initial INVITE. And probably break a lot of 
>> implementations.
>>
>> I'm not certain one way or the other on this. My inclination is that 
>> it can refresh the target, but the UAS won't know if it has.
> 

I agree. But I still see justification for allowing it:

1) its simpler for the UAC - common logic for initial- and re- invite.
2) its more likely to be consistent with current behavior
3) if the UAC and/or the UAS doesn't support reliable provisionals,
    and the UAC does need to change the target, it seems better
    to do it than not.

but I still wouldn't *recommend* it. Certainly there are cases where 
this could lead to inconsistencies and thus a failed call. I think the 
preferred behavior in that situation would be:

- send final response to reINVITE (e.g. 487.)
- immediately send new reINVITE to refresh the target.
   (It can go before receiving the ACK. If it causes glare due to
   loss of the final response, then deal with it then.)

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Jul 2009 17:40:51 +0200

Hi, 

>>>>So, unless I am wrong we would say that it is possible to provide 
>>>>the remote target unreliably for an initial INVITE, but it is not 
>>>>possible to update it unreliably for a re-INVITE.
>>>
implementations.
>yes, that is the problem. If we let unreliable responses change things,
the UAS is not aware if the UAC received them or 
>not. So, if the UAS later sends a 4xx for the re-INVITE, it does not
know if the UAC has refreshed the target (if the UAC 
>received the response) or not (if the UAC did not receive it). We would
be creating a mechanism that gets UAs out of 
>sync.

It was probably a misstake to allow the unreliable 18x to provide the
target for the initial INVITE, but I guess it is too late to change that
now...
 
I share Paul's issue with potential implementation impacts, but I guess
this is something we just have to do - otherwise we will end up with the
problem Gonzalo describes.

This is probably one thing it would be good to get some feedback from
SIPit, on how implementations behave.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Jul 2009 17:48:17 +0200

Hi,

> 2) its more likely to be consistent with current behavior

how simpler and how consistent with current behavior it is would depend 
on each particular implementation. In any case, RFC3261 does not allow 
unreliable responses to refresh targets. RFC3261 only allows 2xx 
responses to do that. Therefore, we are consistent with what is 
currently specified. We are not specifying anything new here.

>    and the UAC does need to change the target, it seems better

If the UAS wants to change its location, it can send an UPDATE instead 
of an unreliable response. That would work just fine.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jul 2009 21:18:50 -0400

> currently specified. We are not specifying anything new here.

OK, sorry about that.

> of an unreliable response. That would work just fine.

If UPDATE is supported.
But maybe we should stop worrying about things that don't.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 29 Jul 2009 14:25:36 +0200

Hi,

> But maybe we should stop worrying about things that don't.

I will make sure the draft covers the different possibilities (e.g., no 
support for 100rel or UPDATE).

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 29 Jul 2009 21:22:10 +0200

Hi,

If you don't support UPDATE you can always send a re-INVITE, once the
ongoing re-INVITE is done.

Regards,

Christer 

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Wednesday, July 29, 2009 3:26 PM
To: Paul Kyzivat
Cc: Christer Holmberg; [email-masked]; SIPCORE
Subject: Re: [sipcore] New revision of the re-INVITE handling draft

Hi,

Thanks,

Gonzalo

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 30 Jul 2009 18:17:44 +0900

Hi,

I want to confirm one basic points, 

>within a re-INVITE that eventually failed).

I don't dislike this rule. But AFAIK RFC3261 and 3262 don't allow
(even if reliable) provisional responses to refresh targets.
Therefore I think this is a normative change.

Regards,

Shinji

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 30 Jul 2009 14:41:28 +0200

Hi,

please, read Section 8 of the draft. It points to the relevant 
paragraphs of RFC 3261.

Cheers,

Gonzalo