Subject: [sipcore] 答复: target refresh during an incomplete reINVITE-transaction

From: [email-masked]
Date: Thu, 16 Jul 2009 16:08:00 +0800

Hi Shinji,

IMO, it is not elegant solution, as:
1. This is a additional requirement for UA and proxy. 
2. Further the response(of INVITE/Re-INVITE) can be 4xx or 2xx, and the 
difference may has impact on session state.

I have a raw way:

As it is because of the inconsistency of refreshed target and dispatching 
rule by Via, and UAS has get the refreshed target by UPDATE, so the UAS 
can modify the last Via header(which is formed by UAC according to its 
address) to be the new address of UAC. But I am not sure is there any 
proxy will check the Via headers.

The mentioned case is that the response is after the UPDATE(by UAS's 
view). If the final response is before the UDPATE(by UAS's view):
2xx case: The retransmission of 2xx should use modified Via header.
4xx case: 4xx is hop-by-hop, so the 4xx will be sent to the old address of 
UAC. So, it can be missed. The UAC's timer for final response will fire(as 
408), and it can send a new Re-INVITE or just terminate the session.

Thanks.

Gao

OKUMURA Shinji <[email-masked]> 
2009-07-16 14:38

收件人
SIPCORE <[email-masked]>
抄送
[email-masked], Paul Kyzivat <[email-masked]>
主题
target refresh during an incomplete reINVITE-transaction

Hi Gao,

I think this issue may be discussed previously.

During an incomplete reINVITE-transaction, if UAC's IP address
is changed,

UAC behavior when sending the UPDATE request to refresh local target
  MAY send CANCEL
  DO NOT expect 4xx responce for reINVITE
  If necessary, send new reINVITE (in the same dialog)

UAS behavior when receiving the UPDATE request to refresh remote target
  If tactful, MAY send 4xx responce for reINVITE
  DO expect CANCEL

Server transaction (nearest UAC)
  If very very tactful, would forward 4xx to new IP address.
  but I'm not sure it cause no problem.

Regards,
Shinji

[email-masked]
>Hi,
>
>Then, it seems a real problem for inconsistency of refreshed target and 
>dispatching rule by Via. 
>
>Paul has given out some BCP way. Do you have some thought about solutions 

>in theory?
>
>Thanks.
>
>Gao
>
>===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : [email-masked]
>===================================
>
>OKUMURA Shinji <[email-masked]> 
>2009-07-16 12:29
>
>Hi, Gao
>
>I seem you don't still catch his point. He has been talking about
>a Via header of not a proxy but an UAC. the server transaction send
>a responce of the reINVITE to the old address of an UAC, even if
>UPDATE request had refreshed UAC's local target(ie. IP address).
>
>It is a basic rule described in RFC3261. RFC3311 does NOT change it.
>
>Regards,
>Shinji
>
>[email-masked]
>>Hi,
>>
>>I catch your point now. You mean that the middle-box, such as proxy, 
>>adding Via in the INVITE. Then the proxy is now non-functional, making 
the 
>>response unreachable.
>>
>>But I think the solutions should not be in protocol level. The solutions 

>>can be:
>>
>>1. Fault tolerance. (ie. crashing of P-CSCF/S-CSCF)
>>
>>2. Issue new INVITE replace the old one. (ie. changing P-CSCF)
>>
>>Thanks.
>>
>>Gao
>>
>>===================================
>> Zip    : 210012
>> Tel    : 87211
>> Tel2   :(+86)-025-52877211
>> e_mail : [email-masked]
>>===================================
>>
>>
>>
>>Paul Kyzivat <[email-masked]> 
>>
>>[email-masked] wrote:
>>
>>> If |he UAC decides to fix this by sending an UPDATE before completion 
of
>>> the reINVITE, then it may succeed in getting the remote target changed
>>> at the UAS. But the *UAS is still obligated to send the remaining
>>> responses to the address in the Via, which is the old address. *
>>> 
>>> [Gao] It is in RFC3261, but RFC3311 has the definition as:
>>> 
>>> from RFC3311:
>>> 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*.
>>> 
>>> So, it should be the new address here.
>>
>>You miss my point.
>>
>>Its not about the Contact placed *in* the 2xx response.
>>Its about the address to which the response is delivered.
>>That is dictated by the Via headers in the INVITE request.
>>Those are not affected by the target refresh.
>>
>>                 Thanks,
>>                 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: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jul 2009 19:08:50 -0400

IMO it is a bad idea, dangerous precedent, and not very functional, to
have the UAS modifying the Via when receiving a target refresh.

This is way out of line. Also, its not that unusual for middleboxes to
obscure Vias, in which case the UAS won't even find the entry that needs
to be modified.

The use case is an infrequent one, though it could be important. I
spelled out how this could be handled without fixing the Via, and that
is all consistent with current rules. The only thing that is required is
that the target refresh by the UPDATE must not be rolled back if the
enclosing INVITE fails. IMO that is reasonable, even if it is a special
case.

	Thanks,
	Paul

[email-masked] wrote:
> As it is because of the inconsistency of refreshed target and 
> dispatching rule by Via, and UAS has get the refreshed target by UPDATE, 
> so the UAS can modify the last Via header(which is formed by UAC 
> according to its address) to be the new address of UAC. *But I am not 
> sure is there any proxy will check the Via headers.*
> 
> 4xx case: 4xx is hop-by-hop, so the 4xx will be sent to the old address 
> of UAC. So, it can be missed. The UAC's timer for final response will 
> fire(as 408), and it can send a new Re-INVITE or just terminate the 
> session.
> 
> Thanks.
> 
> Gao
> 
> 
> 
> *OKUMURA Shinji <[email-masked]>*
> 
> 2009-07-16 14:38
> 
> 	
> 收件人
>  >>adding Via in the INVITE. Then the proxy is now non-functional, 
> making the
>  >>response unreachable.
>  >>
>  >>> If |he UAC decides to fix this by sending an UPDATE before 
> completion of
>  >>>    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

---

From: [email-masked]
Date: Fri, 17 Jul 2009 12:39:25 +0800

inlines.

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2009-07-17 07:08

收件人
[email-masked]
抄送
SIPCORE <[email-masked]>, OKUMURA Shinji <[email-masked]>
主题
Re: [sipcore] 答复: target refresh during an incomplete 
reINVITE-transaction

[Gao] IMO, when middleboxes act as B2BUA, it is reasonable to obscure 
Vias. And it is the B2BUA's UAS need to modify the last Via while 
transfering the response.
Other proxy behavioring middlebox should not do so. But I admit that there 
are middleboxs which aren't B2BUA doing as you said in current network. So
， IMO, it *should not* be bad(*if* it is defined as early as RFC3261, it 
may be OK), but not practical in current network.

The use case is an infrequent one, though it could be important. I spelled 

out how this could be handled without fixing the Via, and that
is all consistent with current rules.

[Gao] I agree with you. But as the moving speed is faster(such as more and 
more high speed trains in China), the probability of losing old IP Access 
while moving may be increaseing. So. the solution is needful. And your way 
is OK as I said in previous mails.

  The only thing that is required is
that the target refresh by the UPDATE must not be rolled back if the
enclosing INVITE fails. IMO that is reasonable, even if it is a special
case.

[Gao] IMO, draft-camarillo-sipcore-reinvite-00 has no conflict with this.

                 Thanks,
                 Paul

> sure is there any proxy will check the Via headers.
> 
while

> 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.
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 17 Jul 2009 17:36:53 +0900

Hi Paul,

>enclosing INVITE fails. IMO that is reasonable, even if it is a special

I agree. And I have a battery of question regarding to this
procedure.

Q1. MUST no session parameter(ie. O/A state) that belong to
    the UPDATE transaction be also rolled back?
    (I think no-rollback.)

Q2. If no-rollback, then in precondition case, IS it necessary
    that UAC send new reINVITE with a precondition to revert
    to the pre-INVITE state?
    (I'm confused.)

Q3. MUST no session parameter(ie. O/A state) that belong to
    1st reINVITE and PRACK transaction be also rolled back?
    (I think rollback probably. it cause no problem.)

Q4. Do a reINVITE request and it's reliable provisional responce
    refresh a remote target?
    (I think NO, under the current RFCs.)

I want to hear expert's opinion and wish the draft to give
the answer.

If these already discussed previously, please provide me
the pointer to that discussion.

Regards,
Shinji

>>  >>adding Via in the INVITE. Then the proxy is now non-functional, making the
>>  >>response unreachable.
>>  >>
>>  >>> If |he UAC decides to fix this by sending an UPDATE before completion of
>>  >>>    *an INVITE transaction is in progress*, and it is a UAS for that INVITE
>>  >>> *   field of the 2xx to the INVITE that it placed into the UPDATE request*
>>  >>> *   or response*.
>>  >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2009 10:24:58 -0400

Shinji,

Comments inline

>     the UPDATE transaction be also rolled back?

I think we should treat these as independent questions.
I don't view the need to *not* roll back a target refresh as an argument 
for or against rolling back O/A state.

If we follow draft-camarillo-sipping-reinvite-00 on this, then as I read 
it, the O/A state is bound and will not be rolled back if and only if it 
has begun to be *used*, whereas the remote target will be treated as 
being used *immediately* and so will never be rolled back.

>     that UAC send new reINVITE with a precondition to revert

According to same draft (IIUC) if the preconditions haven't been 
resolved yet then they are not "in use" and so will indeed be rolled back.

Gonzalo: that's right isn't it?

>     (I think rollback probably. it cause no problem.)

I don't understand the question. What is special about the 1st reINVITE? 
I assume it is the same as any reINVITE. The first *INVITE* 
(establishing the dialog) is different, but if that fails you have no 
call, so everything is rolled back.

>     (I think NO, under the current RFCs.)

Yes, I think they do. Doesn't Gonzalo's draft already say that?

	Thanks,
	Paul