Subject: [MMUSIC] hen to send keymod (draft-zhou-mmusic-sdes-keymod-00)

From: "Dan Wing" <[email-masked]>
Date: Sat, 17 Mar 2012 19:43:42 -0700

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

---

From: [email-masked]
Date: Wed, 21 Mar 2012 09:32:40 +0800

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