[Sipping] About offeranswer draft:

gao.yang2@zte.com.cn Wed, 07 April 2010 03:16 UTC

Return-Path: <gao.yang2@zte.com.cn>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABD63A689D for <sipping@core3.amsl.com>; Tue, 6 Apr 2010 20:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.485
X-Spam-Level:
X-Spam-Status: No, score=-99.485 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BitfqEv73HT for <sipping@core3.amsl.com>; Tue, 6 Apr 2010 20:16:18 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1F3433A6827 for <sipping@ietf.org>; Tue, 6 Apr 2010 20:16:17 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 36887478222840; Wed, 7 Apr 2010 11:14:03 +0800 (CST)
Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 62186.2283858608; Wed, 7 Apr 2010 11:13:07 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o373FvnR079222; Wed, 7 Apr 2010 11:16:00 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
To: pkyzivat@cisco.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: <OF80BAC60D.169E6B85-ON482576FE.000E47DF-482576FE.0011EC6B@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Wed, 07 Apr 2010 11:14:07 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-07 11:15:56, Serialize complete at 2010-04-07 11:15:56
Content-Type: multipart/alternative; boundary="=_alternative 0011EC6A482576FE_="
X-MAIL: mse2.zte.com.cn o373FvnR079222
Cc: sipping@ietf.org
Subject: [Sipping] About offeranswer draft:
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2010 03:16:20 -0000

Hi Paul,

While considering one problem in our production's interoperability 
testing, I re-read some parts of offeranswer draft and find something 
might be deserving discussion.

//begin of text(part):
For example, in Figure 1, only the SDP in F6 is the answer.  The SDP
   in the non-reliable response (F2) is the preview of the answer and



Kyzivat & Sawada        Expires September 9, 2010               [Page 8]

Internet-Draft     SIP Usage of the Offer/Answer Model        March 2010


   must be the same as the answer in F6.  Receiving F2, the UAC should
   act as if it receives the answer.
//end of text(part)

[Gao] In fact, UAS sending SDP in non-reliable response is for potential 
early media usage. Considering some UAS may have different address for 
early media channel and the final session, some UAS may send different 
SDP(compare with the answer) in non-reliable response. And I really found 
such equipment inside and outside of ZTE. And considering UAC, I think we 
should allow the UAC ignore the SDP in non-reliable response, while some 
UAC really do not handle any SDP which is not offer or answer. 

But the permissibility of the degree of the difference might be delicate. 
If the non-answer SDP just has different ip address or port, it seams OK. 
If the non-answer SDP has different media streams, it would be hard to 
handle for UAC.


And I re-read correlative part of RFC3261. I don't know that whether 
allowing different SDP(compare with the answer) in non-reliable response 
is violation/correction of current text or not.

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

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.