Subject: Re: [siprec] FW: New Version Notification for draft-eckel-siprec-rtp-rec-03.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 17:06:21 -0400

Charles,

While reading this I got wondering if we need more guidance on the use 
of CNAME. (As referenced in section 5.) Do we need guidance on mapping 
of CNAME to participants?

	Thanks,
	Paul

On 10/31/11 2:00 PM, Charles Eckel (eckelcu) wrote:
> FYI, I have submitted the updated draft and it is available through the SIPREC documents page:
> http://proxy2974.my-addr.net/myaddrproxy.php/https/datatracker.ietf.org/wg/siprec/
>
> It contains editorial changes as well as additional text describing the handling of RTCP packets by the SRC and UAs per the recent SIPREC list discussion.
>
> Cheers,
> Charles
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 31, 2011 10:53 AM
> To: Charles Eckel (eckelcu)
> Cc: Charles Eckel (eckelcu)
> Subject: New Version Notification for draft-eckel-siprec-rtp-rec-03.txt
>
> A new version of I-D, draft-eckel-siprec-rtp-rec-03.txt has been successfully submitted by Charles Eckel and posted to the IETF repository.
>
> Filename:	 draft-eckel-siprec-rtp-rec
> Revision:	 03
> Title:		 Real-time Transport Protocol (RTP) Recommendations for SIPREC
> Creation date:	 2011-10-31
> WG ID:		 Individual Submission
> Number of pages: 13
>
> Abstract:
>     This document provides recommendations and guidelines for RTP and
>     RTCP in the context of SIPREC.  This document exists as a standalone
>     document to facilitate discussion of the RTP recommendations, and it
>     is anticipated that portions of this document will be incorporated
>     into [I-D.ietf-siprec-protocol] rather than this document itself
>     being adopted as a working group document.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 2 Nov 2011 09:59:25 -0700

Hi Paul,

We certainly could. In general, you would have one CNAME value per
participant. I suppose there may be cases in which a participant would
use multiple CNAMEs despite the fact it is not recommended to do so.
Including the CNAME in the participant info is a good thing. I do not
know if we need to plan to support multiple CNAMEs per participant. Is
that your concern?

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
> Sent: Tuesday, November 01, 2011 2:06 PM
> To: [email-masked]
> Subject: Re: [siprec] FW: New Version Notification
fordraft-eckel-siprec-rtp-rec-03.txt
> > FYI, I have submitted the updated draft and it is available through
the SIPREC documents page:
http://proxy2974.my-addr.net/myaddrproxy.php/https/datatracker.ietf.org/
wg/siprec/
> >
> > It contains editorial changes as well as additional text describing
the handling of RTCP packets by
> the SRC and UAs per the recent SIPREC list discussion.
> >
> > Cheers,
> > Charles
> >
> > A new version of I-D, draft-eckel-siprec-rtp-rec-03.txt has been
successfully submitted by Charles
> Eckel and posted to the IETF repository.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2011 13:27:40 -0400

> know if we need to plan to support multiple CNAMEs per participant. Is

This may just be my ignorance of how SSRC and CNAME are supposed to be 
used. I understand that SSRC may change due to collision, and that then 
CNAME is supposed to correlate the stream before/after the change. I 
also gather that CNAME, rather than SSRC, is supposed to be used to 
correlate related streams, like audio and video from same source.

Does that mean that we should reference CNAME in metadata, rather, or in 
addition, to SSRC? Or if we update metadata when SSRC changes does that 
eliminate CNAME for tracking the change?

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 2 Nov 2011 18:08:55 -0700

I think the CNAME would be useful for identifying the participant, in
cases where the media packets from the participant make it to the SRS.
I think the SSRC would be useful for identifying a stream from a
participant, in cases where the media packets from the participant make
it to the SRS directly, or are incorporated into a mixed stream that
ultimately make it to the SRS. In the second case, the SSRC from the
stream sent by the participant to the SRC will be included as a CSRC in
the mixed stream sent by the SRC to the SRS.
So I think both are useful, and the cases and ways in which they are
useful varies depending on the functionality of the SRC.

Cheers,
Charles

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 02, 2011 10:28 AM
> Cc: [email-masked]
> >>> FYI, I have submitted the updated draft and it is available
through

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 4 Nov 2011 10:37:01 -0700

I've been churning on this a bit more. As it stands,
draft-eckel-siprec-rtp-rec does not discuss any relationship or mapping
between RTP/RTCP elements and the SIPREC metadata. It uses the term
participant, but that it is as close it gets. I think such a mapping is
needed, but that this draft is not the appropriate place for it. Are
there other opinions?

Cheers,
Charles 

> From: Charles Eckel (eckelcu)
> Sent: Wednesday, November 02, 2011 6:09 PM
> To: 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: [siprec] FW: New Version Notification
> I think the CNAME would be useful for identifying the participant, in
cases where the media packets
> from the participant make it to the SRS.
participant, in cases where the media
> packets from the participant make it to the SRS directly, or are
incorporated into a mixed stream that
> ultimately make it to the SRS. In the second case, the SSRC from the
stream sent by the participant to
> the SRC will be included as a CSRC in the mixed stream sent by the SRC
to the SRS.
> So I think both are useful, and the cases and ways in which they are
useful varies depending on the
> functionality of the SRC.
> 
> Cheers,
> Charles
> 
through
> > >>>      This document provides recommendations and guidelines for
RTP
> > > and
> > >>>      document to facilitate discussion of the RTP
recommendations,
> > > and it

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Fri, 4 Nov 2011 18:12:02 +0000

Hi Charles,

SIPREC metadata is related to RTP/RTCP through SDP. Lot of media related metadata is possible to be conveyed through SDP and the infrastructure is reused for extensibility. In fact, I have mentioned like a=ssrc parameter for representing SSRC value in SDP. So in case there is a need for extension in SDP, let us discuss here to understand whether it is SIPREC specific or generic enough to discuss in MMUSIC.

Also, I'm not very sure whether CNAME and participant name-id are same in the all scenario, particularly in case of RTP translator and mixer. If so, I would have attempted to avoid the duplicate participant information in Metadata XML.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Charles Eckel (eckelcu)
>Sent: Friday, November 04, 2011 11:07 PM
>To: Paul Kyzivat
>Cc: [email-masked]
>Subject: Re: [siprec] FW: New Version Notification fordraft-eckel-
>siprec-rtp-rec-03.txt
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Nov 2011 18:13:17 -0400

> Also, I'm not very sure whether CNAME and participant name-id are same in the all scenario, particularly in case of RTP translator and mixer. If so, I would have attempted to avoid the duplicate pa…

Check out RFC 6222, for latest guidance on assigning CNAMEs. This pretty 
much guarantees that CNAMEs are distinct from the participant name-id. I 
think that also means that a single participant may have multiple CNAMEs.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 14 Nov 2011 15:34:20 +0530

Charles,

Sorry for getting late on this. I am ok with adding a new attribute in
participant element to represent the CNAME.

I will add this item to metadata slide deck and close it in the meeting.

Regards,
Ram

> Behalf Of Charles Eckel (eckelcu)
> Sent: Thursday, November 03, 2011 9:09 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [siprec] FW: New Version Notificationfordraft-eckel-
> siprec-rtp-rec-03.txt
> 
> > > know if we need to plan to support multiple CNAMEs per
participant.
> Is
> > Does that mean that we should reference CNAME in metadata, rather,
or
> in
> > >> While reading this I got wondering if we need more guidance on
the
> use
> http://proxy2974.my-
> addr.net/myaddrproxy.php/https/datatracker.ietf.org/
> > > wg/siprec/
> > >>>