[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] [sip] extensions of "handling" parameter of Content-Disposition header
As Eric already been questioned (I apologize if I missed the response), have you considered XCON/MEDIACTRL to provide this functionality?
You might be able to piece together some things to get this to work, but it's not likely to inter-op with other implementations in terms of client manipulation of a conference - that's the idea behind XCON/MEDIACTRL - to allow an authorized participant to have control the conference/focus. While the XCON FW might seem to be overkill, the protocol itself is fairly straightforward (in the works), thus you could implement the basics and get the functionality you're looking for.
Regards,
Mary.
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Sedlacek Ivo
Sent: Tuesday, September 23, 2008 1:41 AM
To: 'ext Paul Kyzivat'
Cc: 'SIP IETF'
Subject: Re: [Sip] [sip] extensions of "handling" parameter of Content-Disposition header
Hello,
see further explanation below.
for some reason the initial mail was sent again, sorry about that.
Kind regards
Ivo Sedlacek
Siemens
PSE CZ TMM MMA8
phone: +420 5 3877 6532
email: ivo.sedlacek.ext at nsn.com, ivo.sedlacek at siemens.com
Mailcode: tL3PbjBL
-----Original Message-----
From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 23. září 2008 6:46
To: Sedlacek Ivo
Cc: 'ext Eric Burger'; 'SIP IETF'
Subject: Re: [Sip] [sip] extensions of "handling" parameter of Content-Disposition header
Sedlacek Ivo wrote:
> > Hello Eric,
> >
> > thanks for your mail.
> >
> >> What precisely is the use case behind your request?
> >
> > The use case is to initiate sharing of a resource (stored at an
> > external
> > server) to participants of a tightly coupled conference (RFC4353).
>
> Can you give a concrete example of what this means?
> I'm still totally in the dark about what you are trying to do.
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.
> > After the tightly coupled conference is established, a participating
> > client sends a SIP request containing a MIME body of MIME type
> > message/external-body (RFC2017) towards the focus. The "URL"
> > parameter of the Content-Type header of the MIME body contains URL
> > of the resource to be shared. The "handling" parameter with value
> > "xyz" of the Content-Disposition header of the MIME body indicates
> > to the focus that this is not a regular message/external-body but it
> > is a request to initiate sharing of the resource to participants.
> >
> > When the focus receives a SIP request with the MIME body of MIME
> > type message/external-body with the "handling" parameter of
> > Content-Dispotion header set to "xyz", the focus will start sharing
> > the resource indicated by the URL of the MIME body of MIME type message/external-body.
>
> I have no clue what it means for the focus to share the resource.
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.
>
> I'm going to reserve judgment about this topic until I have an idea
> what you are trying to do.
>
> Thanks,
> Paul
>
> > If the focus received the SIP request with the MIME body of MIME
> > type message/external-body WITHOUT the "handling" parameter of
> > Content-Dispotion header set to "xyz", the focus would behave
> > differently - e.g. initiate the SIP requests towards the other
> > participants and include there the MIME body.
> >
> > Other considered method is to initiate sharing of the resource using
> > 5.2. Adding Participants of RFC4353 - the participating client
> > indicates to the focus to add the resource as added participant. The
> > focus applies a special policy when the focus detects the referred
> > URI is not a user.
> >
> > Kind regards
> >
> > *Ivo Sedlacek*
> > Siemens
> > PSE CZ TMM MMA8
> > phone: +420 5 3877 6532 <tel:+420543106532>
> > email: ivo.sedlacek.ext at nsn.com <mailto:ivo.sedlacek.ext at nsn.com>,
> > ivo.sedlacek at siemens.com <mailto:ivo.sedlacek at siemens.com>
> >
> > Mailcode: tL3PbjBL
> >
> >
> > --------------------------------------------------------------------
> > ----
> > *From:* ext Eric Burger [mailto:eburger at standardstrack.com]
> > *Sent:* 19. září 2008 22:04
> > *To:* Sedlacek Ivo
> > *Cc:* SIP IETF
> > *Subject:* Re: [Sip] [sip] extensions of "handling" parameter of
> > Content-Disposition header
> >
> > Absolutely. Here is the deal:
> >
> > ;handling is a parameter that tells the UAS that is MUST (or MAY)
> > understand the body part in its processing of the SIP message.
> > "Understand" usually means "can process" the body part, but that is
> > an implementation issue.
> >
> > Content-Disposition is a parameter that tells the UAS what to do
> > with the body part.
> >
> > Now, looking at your question, Content-Disposition is probably not
> > what you want, either. You say, "to signal a particular action which
> > the sender requests from the recipient". That implies signaling.
> > Content-Disposition is not signaling. Content-Disposition is a hint
> > to the UAS as to what it should do with the body. If you want to
> > signal an action at the UAS, then you more likely want one of (new)
> > INFO packages, PUBLISH/SUBSCRIBE, or a new SIP header.
> >
> > What precisely is the use case behind your request?
> >
> >
> > On Sep 19, 2008, at 7:16 AM, Sedlacek Ivo wrote:
> >
> >> Just to be absolutely sure - do you mean that it is more
> >> appropriate to create a new disposition-type of the
> >> Content-Disposition header (rather than creating new "handling" parameter values)? Thanks.
> >>
> >> Kind regards
> >>
> >> Ivo Sedlacek
> >> Siemens
> >> PSE CZ TMM MMA8
> >> phone: +420 5 3877 6532
> >> email: ivo.sedlacek.ext at nsn.com <mailto:ivo.sedlacek.ext at nsn.com>,
> >> ivo.sedlacek at siemens.com <mailto:ivo.sedlacek at siemens.com>
> >>
> >> Mailcode: tL3PbjBL
> >>
> >> -----Original Message-----
> >> From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
> >> Sent: 19. září 2008 14:08
> >> To: Sedlacek Ivo
> >> Cc: sip at ietf.org <mailto:sip at ietf.org>
> >> Subject: Re: [Sip] [sip] extensions of "handling" parameter of
> >> Content-Disposition header
> >>
> >> I can't think why you would want to have added values for the
> >> handling parameter. IMO what you want to do would be better served
> >> by values of the Content-Disposition itself.
> >>
> >> Thanks,
> >> Paul
> >>
> >> Sedlacek Ivo wrote:
> >> > Hello,
> >> >
> >> > can anyone please give me an expert opinion on possible
> >> > extensions of "handling" parameter defined in RFC3204/RFC3459?
> >> >
> >> > Is it appropriate to extend and use the "handling" parameter of
> >> > Content-Disposition header of a MIME body inserted in a SIP
> >> > request
to
> >> > signal a particular action which the sender requests from the
recipient?
> >> >
> >> > For example - if the "handling" parameter contained value "XYZ",
> >> > the
SIP
> >> > request recipient would do a special action ActionXYZ using the
> >> > MIME body. If the MIME body was included in the SIP request
> >> > without the "handling" parameter, the recipient would NOT do the
> >> > special action
XYZ
> >> > and instead would just store or render the MIME body.
> >> >
> >> > AFAIK, RFC3204 defines parameter "handling" of
> >> > Content-Disposition header of a MIME body with two defined parameter values "required"
and
> >> > "optional" and allows for possible future extensions. RFC3204
> >> > also states "The handling parameter, handling-parm, describes how
> >> > the UAS should react if it receives a message body whose content
> >> > type or disposition type it does not understand". RFC3459 says
> >> > "The protocol described here is identical in functionality to RFC
> >> > 3204 with respect
to
> >> > SIP.".
> >> >
> >> > Kind regards
> >> >
> >> > *Ivo Sedlacek*
> >> > Siemens
> >> > PSE CZ TMM MMA8
> >> > phone: +420 5 3877 6532 <tel:+420543106532>
> >> > email: ivo.sedlacek.ext at nsn.com <mailto:ivo.sedlacek.ext at nsn.com>
> >> <mailto:ivo.sedlacek.ext at nsn.com>,
> >> > ivo.sedlacek at siemens.com <mailto:ivo.sedlacek at siemens.com>
> >> <mailto:ivo.sedlacek at siemens.com>
> >> >
> >> > Mailcode: tL3PbjBL
> >> >
> >> >
> >> >
> >> >
------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > 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
> >> <mailto:sip-implementors at cs.columbia.edu> for questions on current
> >> sip
> >> > Use sipping at ietf.org <mailto:sipping at ietf.org> 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
> >> sip-implementors at cs.columbia.edu
> >> <mailto:sip-implementors at cs.columbia.edu> for questions on current
> >> sip Use sipping at ietf.org <mailto:sipping at ietf.org> 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip