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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jul 2009 09:32:43 -0400

[email-masked] wrote:
> 
> Hi Paul,
> 
> As Ini-INVITE and it's reponses has different routing to susquent 
> request, including Re-INVITE and UPDATE, then it is better to Cancel the 
> ongoing Ini-INVITE and following a new Ini-INVITE(BTW, I think sending a 
> new Ini-INVITE with replace is same).

That is consistent with point I was making.

> While considering Re-INVITE, having the same *routing set* as subsequent 
> UPDATE, it may send target refresh UPDATE during ongoing Re-INVITE. If 
> there is something wrong with transporting Re-INVITE's response, there 
> will be the same problem with transporting UPDATE.

I don't agree - the responses to the reinvite are a problem even though
the UPDATE is not.

Suppose UAC for reINVITE gets a new IP address, different from the one
it included in the contact and via of the reINVITE. And assume for
simplicity that there are no Record-Route's.

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. If the
old address is now non-functional then the responses won't arrive and
the reINVITE will time out.

Even though it times out, it still can have the desired effect of
changing the target, so long as that isn't rolled back when the reINVITE
times out.

An alternative would be to CANCEL the reINVITE and then send a new
request to refresh the dialog. But there is a problem here: CANCEL is
not a target refresh request. So even if it reaches its target and does
its job, the response is likely not to arrive. Nor is the 487 response
to the canceled reINVITE. So while this might work, there will be no way
for the UAC to know it worked.

So now I'm thinking that the UPDATE, is the right first step. If the
UPDATE is successful, then a CANCEL could be sent (using the new
Contact) to terminate the reINVITE early. In that case the response to
the CANCEL should be received even though the response to the reINVITE
will not be. After that, and perhaps a delay, a new reINVITE - a retry
of the earlier one - could be attempted using the new address.

This all hinges on the mid-invite UPDATE-based target refresh not being
rolled back when the invite fails.

> And then, the UA can 
> terminate the session/call. So, sending target refresh UPDATE during 
> ongoing Re-INVITE is not bad(than after the Re-INVITE).

I guess we ultimately agree here.

> There is another interesting case for changing address problem:
> Considering wireless access network and UA's roam, UA get into a visited 
> domain which can afford IMS accessing beyond GPRS accessing. Then the 
> session need to be transfered to the new P-CSCF in the current visited 
> domain. In this use case, just refresh UA's target is not enough because 
> of the original P-CSCF should not be in the dialog's route set and the 
> new P-CSCF must be in the route set. Sending a new INVITE to replace the 
> original session and dialog is needed.

Well, that is a problem for IMS.

However we can consider the earlier failure scenario when there are
Record-Route entries. In general I don't think it affects the analysis
at all. The proxies in the route-set are supposed to accept the target
refresh.

	Thanks,
	Paul

> Thanks.
> 
> Gao
> 
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : [email-masked]
> ===================================
> 
> 
> *Paul Kyzivat <[email-masked]>*
> 
> 2009-07-14 23:04
> 
> 	
> 收件人
> 	[email-masked]
> 抄送
> 	OKUMURA Shinji <[email-masked]>, SIPCORE <[email-masked]>
> 主题
> 	Re: [sipcore] 答复: Re:  New revision of the re-INVITE handling draft
> 
> 
> 	
> 
> 
> 
> 
> 
> 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:
>  >
>  > 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,
>  >
>  > 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]
>  >  >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.
>  >
>  > 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
>  >
>  >  >And then, we can get the correct session state by the way proposed in
>  >  >draft-camarillo-sipcore-reinvite-00.
>  >  >
>  >  >Gao
>  >
>  >
>  >
>  > --------------------------------------------------------
>  > 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
> 
> 
> 
> --------------------------------------------------------
> 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.