Hello all, I want to make a supplement because I think the new-introduced participant in the use case is a SEND-ONLY participant (fetching ... to the participants), how about the solution in this situation?
To Eric: the statement on the authentication in RFC4483 is as follow, is it enough? "For confidentiality, integrity, and authentication, this content indirection mechanism relies on the security mechanisms outlined in RFC 3261. In particular, the usage of S/MIME as defined in section 23 of RFC 3261 provides the necessary mechanism to ensure integrity, protection, and confidentiality of the indirect content URI and associated parameters. Securing the transfer of the indirect content is the responsibility of the underlying protocol used for this transfer. If HTTP is used, applications implementing this content indirection method SHOULD support the HTTPS URI scheme for secure transfer of content and MUST support the upgrading of connections to TLS, by using starttls. Note that a failure to complete HTTPS or starttls (for example, due to certificate or encryption mismatch) after having accepted the indirect content in the SIP request is not the same as rejecting the SIP request, and it may require additional user-user communication for correction. Note that this document does not advocate the use of transitive trust. That is, just because the UAS receives a URI from a UAC that the UAS trusts, the UAS SHOULD NOT implicitly trust the object referred to by the URI without establishing its own trust relationship with the URI provider. Access control to the content referenced by the URI is not defined by this specification. Access control mechanisms may be defined by the protocol for the scheme of the indirect content URI." Thanks and Regards Xiangsong ----- Original Message ----- From: Paul Kyzivat To: Sedlacek Ivo Cc: 'SIP IETF' Sent: Tuesday, September 23, 2008 11:42 PM Subject: Re: [Sip] [sip] extensions of "handling" parameter ofContent-Disposition header Sedlacek Ivo wrote: > Hello, > > see further explanation below. > There is a SIP based multiparty conference with a focus - every participant > is connected using a SIP dialog to a central focus, which mixes/switches > Media sent by the participants. > One of the participants wants the focus to fetch e.g. a picture / an audio > clip from an HTTP server / an RTSP server and play it to the conference > participants using their media streams negotiated in SIP dialogs. > Hope this makes this use case clearer. > As mentioned above - by "sharing the resource" I meant the focus is > fetching the picture / audio clip from the HTTP server / the RTSP server and > distribute it using the MSRP / MSRP media streams agreed in the SIP sessions > to the participants. This sounds like a desire to have the conference mixer do something special. As such, something around mediactl might be appropriate. Or, it might be viewed as introducing another sort of participant into the conference. Perhaps this could be done by sending a REFER to the focus, with a URL for the resource in the Refer-To header. Thanks, Paul _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
