Re: [RAI] How to exchange metadata about the media streams established with a SIP session

["Hutton, Andrew" <[e-mail]>]

Hi Paul,

I think we are in sync.

Regards
Andy

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 24 April 2012 15:36
> To: Hutton, Andrew
> Cc: [e-mail]
> Subject: Re: [RAI] How to exchange metadata about the media streams
> established with a SIP session
> 
> On 4/24/12 4:35 AM, Hutton, Andrew wrote:
> > Hi,
> >
> > Whilst I of course agree that it is a good idea to look for a common
> solution if at all possible it is important to keep in mind the charter
> of the various working groups and the environment which the solutions
> will operate.
> >
> > Both the SIPREC and CLUE working groups are chartered to produce SIP
> based solutions which is possibly open to some different
> interpretations but it does impose some constraints on the solution. In
> the SIPREC case we therefore defined a SIP body based mechanism for
> metadata and stated that other mechanism although possible were out of
> scope I have no problem with looking at other mechanisms and would
> participate in any brainstorming session but I don't think we should
> change track regarding the current SIPREC mechanism especially since
> there are quite a few implementations already.
> 
> Andy,
> 
> I don't see how anything that might be done about a general mechanism
> now would affect the output of SIPREC under its current charter. We are
> simply too far down the road for that.
> 
> *Conceivably* some general mechanism might eventually become a
> candidate
> for some future evolution/revision to siprec, but I wouldn't hold my
> breath for that to happen.
> 
> I see info about SIPREC as simply providing some perspective about the
> kinds of things a general mechanism might help with.
> 
> 	Thanks,
> 	Paul
> 
> > Regards
> > Andy
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> >> Paul Kyzivat
> >> Sent: 23 April 2012 20:23
> >> To: [e-mail]
> >> Subject: Re: [RAI] How to exchange metadata about the media streams
> >> established with a SIP session
> >>
> >> On 4/23/12 10:53 AM, Cullen Jennings wrote:
> >>>
> >>> worth nothing the RTCweb folks also want to exchange metadata to do
> >> with labeling streams. I always find just classifying it as
> "metadata"
> >> sort of makes it hard to decide what to do with it. I'd prefer the
> >> groups to specifically outline what data they need to exchange and
> then
> >> I think it becomes clearer the best way to exchange the different
> types
> >> of information. Knowing if the information changes per RTP packet,
> or
> >> only one when the session is set up helps.
> >>
> >> Cullen,
> >>
> >> I agree that just talking about "metadata" isn't especially helpful.
> >> OTOH, getting too far into the weeds about the specifics of the
> >> metadata
> >> makes it hard for people with differing contexts to talk with one
> >> another and find commonalities.
> >>
> >> In CLUE we realize that not all of our metadata can be treated the
> same
> >> way. There are varying degrees of real-time-ed-ness to deal with. We
> >> definitely have some stuff that changes at the signaling rate or
> less,
> >> and some that changes at the media rate, and some stuff that that
> falls
> >> in between. We also have issues that some of the stuff is too big to
> >> reasonably transmit in sip signaling, which we are considering a
> >> separate "data stream" for. We do think that CLUE should be able to
> >> work
> >> with RTCWEB based endpoints. So its possible that the RTCWEB data
> >> stream
> >> mechanism might work for us. But we will need to have it even with
> >> non-rtcweb-endpoints.
> >>
> >> In SIPREC, we have a lot of descriptive stuff, mostly about
> signaling.
> >> The rate is tied to the signaling rate, but possibly about multiple
> >> calls and hence higher in aggregate. We decided that sending in the
> sip
> >> signaling was appropriate for this stuff, though the size of the
> data
> >> precludes doing so over UDP. For this app we decided we could just
> >> require TCP transport for the sip signaling of the recording
> session.
> >> (It doesn't constrain the transport for the calls being recorded.)
> This
> >> could be a problem in some topologies, but seems acceptable for the
> >> application. If there had been a mechanism that for a separate "data
> >> stream" that we could have reused we *might* have found that an
> >> attractive direction.
> >>
> >> ISTM that it would be helpful to have a "brainstorming session" with
> >> some reps from rtcweb, clue, siprec, bfcp, and mediactrl to see
> whether
> >> we can find some common machinery that could support multiples of
> these
> >> cases. I'm thinking that the sctp over udp stack being worked on for
> >> rtcweb might be more broadly applicable, both as a data stream
> >> transport
> >> negotiated with o/a, and maybe as a new sip transport as well.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>> On Feb 28, 2012, at 3:20 , Gonzalo Camarillo wrote:
> >>>
> >>>> Folks,
> >>>>
> >>>> I am sending this email to the RAI list because it is about an
> >>>> architectural issue that affects more than one WG.
> >>>>
> >>>> Both the CLUE and SIPREC WGs have identified the need to exchange
> >>>> metadata about media streams that have been established using SIP.
> >> Both
> >>>> groups need to transport such metadata between SIP UAs.
> >>>>
> >>>> In CLUE, they are studying how to transport their metadata, as
> >>>> documented in:
> >>>> http://tools.ietf.org/html/draft-wenger-clue-transport-01
> >>>>
> >>>> In SIPREC, they are planning to piggyback the metadata in SIP
> >> UPDATEs as
> >>>> an XML-encoded body part. When they need to send a request for
> full
> >>>> state (as opposed to partial state), they use an UPDATE request
> with
> >> a
> >>>> particular body type, as documented in:
> >>>> http://tools.ietf.org/html/draft-ietf-siprec-protocol-02
> >>>>
> >>>> The best way to exchange metadata within a SIP session depends on
> >> the
> >>>> type of metadata and on how the UAs need to interact with each
> other
> >>>> (e.g., a UA simply pushing information to the other UA or a more
> >>>> complicated protocol). Given that SIPREC and CLUE have different
> >>>> metadata and interactions, it may well be that we decide to use a
> >>>> different mechanism in each group. Nevertheless, I think both
> groups
> >>>> would benefit from architecturally-inclined RAI people having a
> look
> >> at
> >>>> their work. Please, continue this discussion focusing on their
> >> specific
> >>>> requirements on either the CLUE list or the SIPREC list.
> >>>>
> >>>> Somewhat related to this issue, the RTCWeb group discussed the use
> >> of
> >>>> SCTP over UDP as a reliable NAT-friendly way to exchange data
> >> between
> >>>> endpoints.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Gonzalo
> >>>>
> >>>> _______________________________________________
> >>>> RAI mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/rai
> >>>
> >>> _______________________________________________
> >>> RAI mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rai
> >>>
> >>
> >> _______________________________________________
> >> RAI mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rai
> >