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

[Paul Kyzivat <[e-mail]>]

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
>