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

gao.yang2@zte.com.cn 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 : gao.yang2@zte.com.cn
> ===================================
> 
> 
> *OKUMURA Shinji <shin@softfront.co.jp>*
> 
> 2009-07-14 10:33
> 
> 	
> 收件人
> 	SIPCORE <sipcore@ietf.org>
> 抄送
> 	gao.yang2@zte.com.cn
> 主题
> 	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?
> 
> gao.yang2@zte.com.cn
>  >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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore