Re: About offeranswer draft: //Is this violation of RFC3261

Hi,

As Christer's description and O/A draft suggestion, we(including me) all 
*hope* the UAC only treate the SDP in frist reliable response as ANSWER. 
And further, UAC finish it's ini-O/A until then(it *MAY* be treated as 
violation of just ignoring the SDP).

So, I think we should evaluate HAS this BEEN violation of RFC3261?

Then, IF it is violation of RFC3261, and we want to do correction as 
above(that is: the UAC MUST only treate the SDP in frist reliable response 
as ANSWER). Then, it is a chance to evaluate how to handle the SDP(sending 
from UAS to UAC) before the ANSWER.

To be honest, I am OK with both of the way(mentioned in the previous 
mail), but a little prefer the second one.

I hope I have make my points clear.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email protected]
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-04-16 16:21 -----

GaoYang140197/user/zte_ltd
2010-04-16 14:44

收件人
Christer Holmberg <[email protected]>
抄送
Paul Kyzivat <[email protected]>, "[email protected]" <[email protected]>
主题
答复: RE: RE: [Sipping] About offeranswer draft:






Hi,

Christer Holmberg <[email protected]> 写于 2010-04-16 
14:24:33:

> Hi,
> 
> I think you need to separate things.
> 
> Since the SDP in the unreliable and reliable responses shall be the 
> same, the UAC should not have to look at the SDP in the reliable 
> response, if it is already "using" the SDP from an unreliable answer.
> 
> However, even if the UAC is using the SDP from an unreliable 
> response, the UAC can not initiate a new offer/answer transaction 
> before it has received the reliable response, because the reliable 
> response terminates the offer/answer transaction.

[Gao] I know it well.
But RFC3261 said UAC MUST treat the SDP(which we think should not be the 
ANSWER, at most treat it as if answer) as answer.

During interworking testing, the other side's people said it is answer, 
then it(the UAC) has finished it's Ini-O/A, what's  normative text can you 
use to convince them?

So, first we should correct RFC3261 clearly that the SDP in unreliable 
response is not ANSWER, even it is the first SDP UAC got. 

Until finishing of the correction, we *MAY* do BCP thing on the handling 
of such SDP. And about BCP, I think there still are two alternative:
1. as O/A draft says, such SDP MUST be the same as the subsequent real 
answer. And UAC MUST using it AS IF answer.

2. Do not do such MUST/MUST NOT restrict, just let UAC's free to handle 
the SDP. If the UAC use it, OK; just ignore it, also OK. But the UAC MUST 
handle the real ANSWER as answer.

Thanks,

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.

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP