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

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

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.

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