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

Hello!

> -----Original Message-----
> From: Fries Steffen [mailto:steffen.fries@siemens.com]
> Sent: den 12 april 2005 12:21
> To: Karl Norrman (KI/EAB)
> Cc: Elisabetta Carrara (AL/EAB); mmusic@ietf.org
> Subject: 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?

Yes.

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

That is up to the local policy.

Regards,
Karl

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