Re: [Sip] [sip] extensions of "handling" parameter ofContent-Disposition header

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip