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

["Ravindran, Parthasarathi" <[e-mail]>]

I agree with Andy as defining the metadata for SIPREC itself took 
nearly 2 years by now, slowly folks understand SIPREC metadata model 
and now we are discussing about SIPREC XML usage with individual 
implementation.

In case we are aiming at come up with the common metadata model 
for RTCWeb and SIPREC, then it takes ages as recording 
is outside the scope of RTCWeb 1.0 usecases and XML vs. JSON will be
just a debate.

I understand the importance of CLUE signaling metadata & SIPREC 
metadata to have commonality in the usage as both are based on SIP and
also SIPREC RTP usage with CLUE media & media-signaling metadata as 
some of the telepresence entities may wish to record telepresence 
session using SIPREC mechanism. I guess that it will be better to forward 
SIPREC metadata draft, SIPREC RTP usage draft to CLUE folks to  
understand any CLUE specific attributes has to be added. But I'm not sure 
whether CLUE is in the state to provide those inputs at this moment.

Also, SIPREC may not require SCTP over UDP transport as most of the 
deployed recording is based on UDP or TCP transport and there is no real
recording requirement to change SIP transport.  

Thanks
Partha  

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Hutton, Andrew
>Sent: Tuesday, April 24, 2012 2:05 PM
>To: Paul Kyzivat; [e-mail]
>Subject: Re: [RAI] How to exchange metadata about the media streams
>established with a SIP session
>
>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
>_______________________________________________
>RAI mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rai