please see inlines.

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : gao.yang2@zte.com.cn
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-04-07 18:00 -----

GaoYang140197/user/zte_ltd 写于 2010-04-07 11:39:18:

> Hi,
> 
> While considering one problem in our productions' interoperability 
> testing, I re-read some parts of offeranswer draft and correlative 
> part of RFC3261. And I find a potential description problem in 
> RFC3261 incidentally.
> 
> //correlative part of RFC3261
> o  If the initial offer is in an INVITE, the answer MUST be in a
>          reliable non-failure message from UAS back to UAC which is
>          correlated to that INVITE.  For this specification, that is
>          only the final 2xx response to that INVITE.  That same exact
>          answer MAY also be placed in any provisional responses sent
>          prior to the answer.  The UAC MUST treat the first session
>          description it receives as the answer, and MUST ignore any
>          session descriptions in subsequent responses to the initial
>          INVITE.
> 
> As the text allow UAS send SDP before the final answer, the first 
> session description UAC receives can not be treated as answer in 
> such cases. And the current text defines that UAC MUST ignore any 
> SDP in subsequent responses to the initial INVITE. whick may make 
> the UAC ignore the real answer in some case.
> 
> I think the description should be: 
> The UAC MUST treat the first session description which is in a 
> reliable non-failure message it receives as the answer, and MUST 
> ignore any session descriptions in subsequent responses to the initial 
INVITE.

This suggestion is based on my another suggestion on offeranswer draft:
http://www.ietf.org/mail-archive/web/sipping/current/msg17504.html

Considering integrality, if the suggestion on offeranswer draft is not 
proper, the correction text for RFC3261's part should have another version 
as:

SDP same as the final answer MAY also be placed in any unreliable 
provisional responses sent prior to the answer.  If the the first session 
description the UAC receives is not answer, the UAC MUST treat the SDP as 
if the answer, and MUST ignore any session descriptions in subsequent 
responses to the initial INVITE.

So, I think we should evaluate the necessity of the sameness of the answer 
and the previous SDPs. 

> 
> And if the problem is exist, where should be the correction's location?
> I think draft-ietf-sipcore-reinvite-03 is not proper, as it aims for
> Re-INVITE. And a new draft for such tiny *potential* problem is also
> not proper.
> 
> Thanks,
> 
> Gao
> 
> ===================================
>  Zip    : 210012
>  Tel    : 87211
>  Tel2   :(+86)-025-52877211
>  e_mail : gao.yang2@zte.com.cn
> ===================================


--------------------------------------------------------
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.