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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jul 2009 12:13:56 -0400

[email-masked] wrote:

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

---

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

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]
2009-07-16 00:13

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

You miss my point.

                 Thanks,
                 Paul
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
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: Thu, 16 Jul 2009 13:29:24 +0900

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]
>> If |he UAC decides to fix this by sending an UPDATE before completion of

---

From: [email-masked]
Date: Thu, 16 Jul 2009 12:57:23 +0800

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

OKUMURA Shinji <[email-masked]> 
2009-07-16 12:29

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

Hi, Gao

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 16 Jul 2009 15:39:47 +0900

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]