RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.

Hi Karl,

thank you for the answer. Does it mean you should send the MIKEY container
even if you don't want to change any of the parameter?

To my other question, does the "no" mean, the receiver of the 488 has to
interpret it in some way?

Regards
	Steffen 

> -----Original Message-----
> From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com] 
> Sent: Tuesday, April 12, 2005 11:59 AM
> To: Fries Steffen
> Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org
> Subject: RE: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.
> 
> Hello!
> 
> As we understand the offer/answer model (rfc3264), you should 
> keep the parameters that you do not wish to change constant 
> in the re-INVITE. So we also assume that if you try to comply 
> to the offer/answer model, you will include the MIKEY 
> parameter, but "ignore" it at the receiver during the SDP 
> processing as it has not been changed.
> 
> Regarding your question in your previous mail, the answer is no.
> 
> Regards,
> MIKEY-people
> 
> > ---------------------------- Original Message
> > ----------------------------
> > Subject: [MMUSIC] Question to MIKEY embedding with kmgmt-ext.
> > From:    "Fries Steffen" <steffen.fries@siemens.com>
> > Date:    Mon, April 11, 2005 8:55 am
> > To:      elisabetta.carrara@ericsson.com
> > Cc:      mmusic@ietf.org
> > --------------------------------------------------------------
> > ------------
> > 
> > Hi Elisabetta,
> > 
> > recently a question came up in the usage of the key management 
> > extentions for SIP to use MIKEY:
> > 
> > Section 3.1.2 of draft-ietf-mmusic-kmgmt-ext-14 contains 
> the following
> > statement:
> > 
> > "If the key management rejects the offer and the session 
> needs to be 
> > aborted, the answerer SHOULD return a "488 Not Acceptable Here" 
> > message, optionally also including one or more Warning 
> headers (a 306 
> > "Attribute not understood" when one of the parameters is not 
> > supported, and a 399 "Miscellaneous warning" with arbitrary 
> > information to be presented to a human user or logged, see Section 
> > 20.43 in [SIP]). Further details about the cause of failure MAY be 
> > described in an included message from the key management 
> protocol. The 
> > session is then aborted (and it is up to local policy or 
> end user to 
> > decide how to continue)."
> > 
> > Concerning the sentence in bold (The sentence before the 
> last sentence 
> > in quotes), how does it do that in the following scenario?:
> > A UA receives an INVITE request containing an SDP offer 
> with a MIKEY 
> > I_MESSAGE that is for some reason unacceptable. The 
> receiving UA will 
> > return a 488 response, which does not contain an SDP 
> answer. Therefore 
> > there is no way of embedding a MIKEY R_MESSAGE to indicate 
> the error. 
> > Is there any way to signla the MIKEY error in this case?
> > 
> > Regards
> > 	Steffen
> > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> > 
> > 
> > 
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic