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

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Apr 2012 07:53:48 -0700

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.

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 15:22:43 -0400

> 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 pr…

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 24 Apr 2012 10:35:24 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: 23 April 2012 20:23
> To: [email-masked]
> Subject: Re: [RAI] How to exchange metadata about the media streams
> established with a SIP session
> 
> > 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,
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 24 Apr 2012 09:34:31 +0000

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  

>Hutton, Andrew
>Sent: Tuesday, April 24, 2012 2:05 PM
>To: Paul Kyzivat; [email-masked]
>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
>
>
>
>
>> 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,
>>
>> 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.
>>
>> 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.
>>
>> 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
>>
>> >> state (as opposed to partial state), they use an UPDATE request
>> >> with
>> a
>> >> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Apr 2012 09:35:58 -0400

> 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…

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

>> metadata

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 24 Apr 2012 17:57:07 +0200

Hi Paul,

I think we are in sync.

Regards
Andy

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 24 April 2012 15:36
> To: Hutton, Andrew
> Cc: [email-masked]
> 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,
> 
> then
> same
> sip
> This
> whether
> other
> >>>> would benefit from architecturally-inclined RAI people having a
> look
> >> at