[MMUSIC] 答复: hen to send keymod (draft-zhou-mmusic-sdes-keymod-00)
zhou.sujing@zte.com.cn Wed, 21 March 2012 01:33 UTC
Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D532021E8084 for <mmusic@ietfa.amsl.com>; Tue, 20 Mar 2012 18:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.569
X-Spam-Level:
X-Spam-Status: No, score=-94.569 tagged_above=-999 required=5 tests=[AWL=-1.779, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53sc7VbkLtSO for <mmusic@ietfa.amsl.com>; Tue, 20 Mar 2012 18:33:09 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7B321E8020 for <mmusic@ietf.org>; Tue, 20 Mar 2012 18:33:08 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280978252052; Wed, 21 Mar 2012 08:58:58 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 95246.2712434073; Wed, 21 Mar 2012 09:32:45 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2L1WmNF062079; Wed, 21 Mar 2012 09:32:48 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <066801cd04b0$eeb49660$cc1dc320$@com>
To: Dan Wing <dwing@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF192558DC.944E7784-ON482579C8.0008091A-482579C8.00087F28@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Wed, 21 Mar 2012 09:32:40 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-21 09:32:49, Serialize complete at 2012-03-21 09:32:49
Content-Type: multipart/alternative; boundary="=_alternative 00087F28482579C8_="
X-MAIL: mse02.zte.com.cn q2L1WmNF062079
Cc: xie.zhenhua@zte.com.cn, tian.tian1@zte.com.cn, mmusic@ietf.org
Subject: [MMUSIC] 答复: hen to send keymod (draft-zhou-mmusic-sdes-keymod-00)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2012 01:33:10 -0000
Hi， Wing
Your point is good, I may update our draft (in 01 version) like the
following paragraph:
" 3.1. Generating the Initial Offer - Unicast Streams
The generation of the initial offer for a unicast stream MUST follow
that of the crypto attribute RFC4568 [RFC4568], and MAY
also include an additional "keymod" parameter with keymod-val being
NULL. It indicates to the ultimate answerer that the offerer wants
to employ the mechanism specified in
this document, a key agreement mechanism with a higher security level
than the original SDES.
"
So that answerer does not need to know it is in a re-targeting or forking
scenario,
it is offerer suggesting use keymod mechanism.
Regards~~~
-Sujing Zhou
"Dan Wing" <dwing@cisco.com> 写于 2012-03-18 10:43:42:
> To be effective, draft-zhou-mmusic-sdes-keymod needs the Answerer to
send
> the "keymod" extension if it knows, or believes, the INVITE was
re-targeted
> or forked. I have two questions:
>
> I see for the described re-targeting case (Section 5.1 of
> draft-zhou-mmusic-sdes-keymod-00), a "cause" parameter [RFC4458] can be
a
> useful indicator that a call was re-targeted. Is the "cause" parameter
> always present when a call is re-targeted?
>
> How does the Answerer know if a call was forked?
>
> -d
>
>
>
>
>