Subject: [siprec] Comments on draft-ietf-siprec-protocol-06

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 16:32:22 -0400

Section 8.2.2:

    The SSRCs from the contributing UA SHOULD be conveyed as CSRCs
    identifiers within this stream.

The SSRCs of the contributing UAs that are being mixed will typically 
come from independent RTP sessions, and so there could be collisions. 
The SRC must cope with this - perhaps by remapping SSRCs.

Is the following from 8.3.2 intended to deal with this?

    In order to preserve the mapping of media to participant within the
    CSs in the RS, the SRC SHOULD map each unique combination of CNAME/
    SSRC within the CSs to a unique SSRC within the RS.  The CNAMEs used
    in the CSs are not preserved within the RS.  The SRS relies on the
    SIPREC metadata to determine the participants included within each
    multiplexed stream.  The SRC MUST avoid SSRC collisions, rewriting
    SSRCs if necessary.  In doing to, the SRC acts as an RTP endpoint.

But that has its own problems:

- Do you really mean a unique SSRC within the *RS*???
   In particular, if the SRC is recording many concurrent independent
   CSs, with each CS in a separate RTP session (m-line), must it assign
   unique SSRCs across all the RTP sessions? Or only across all the
   parts of the same CS? (There is similar language in 8.3.3 without
   these problems. Maybe it just needs to be used here too.)

- If CNAMEs in the CSs aren't preserved in the RS, is there a 1:1
   relation between them? If not, then sync between RTP streams in the CS
   won't be possible. If so, I guess it should be mentioned.

In general, I think we need some discussion of what should happen if RTP 
stream multiplexing is being used within a single CS RTP session. ISTM 
that there should be a way for the SRC to convey enough info to the SRS 
so that it can understand how RTP streams were / weren't multiplexed in 
the CS and so reconstruct things properly. (OTOH I don't think the SRC 
need be REQUIRED to convey this much info.)

Section 9.1:

    A full metadata snapshot describes all
    the recorded streams and all metadata associated with the recording
    session.

This is fine as far as it goes. But I think it would helpful to say a 
bit more:

    A full metadata snapshot describes all the sessions, participants,
    streams subject to recording at the time of the snapshot, and all
    associated metadata.

(I struggled with this. I hope it isn't too cumbersome.)

My point is to indicate that this isn't expected to include historical 
data, such as sessions that were previously active but that have ended.

Figure 12:

It doesn't hurt, but its not necessary to list application/rs-metadata 
in the Accept. (Its only *sent*, not *received*.)

Section 9.2:

    Note that the SRS MAY generate an INVITE
    request without an SDP offer but this MUST NOT include a metadata
    snapshot request.

This seems wrong. Fix it by: s/without/with/

Section 11.1.1:

    If the a=recordpref attribute is
    omitted, then the recording preference would be assumed to be the
    recording preference set in a previous SDP offer or answer.

I believe this to be unwise. One can never be certain that you are 
talking to the same entity as before. (There could have been a 3pcc 
transfer.) So I think we must assume that the lack of the attribute 
means lack of preference.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 27 Jul 2012 19:43:47 +0000

Hi Paul,

Thanks for the feedback. Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Thursday, July 26, 2012 1:32 PM
> To: [email-masked]
> Subject: [siprec] Comments on draft-ietf-siprec-protocol-06
> 
> Section 8.2.2:
> 

No, section 8.3.3 is intended to deal with this, specifically:

   In order to preserve the mapping of media to participant within the
   CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to
   a unique CNAME within the RS.  Additionally, the SRC SHOULD map each
   unique combination of CNAME/SSRC within the CSs to a unique CNAME/
   SSRC within the RS.  The SRC MUST avoid SSRC collisions, rewriting
   SSRCs if necessary when used as CSRCs in the RS.  In doing to, the
   SRC acts as an RTP mixer.
 
> But that has its own problems:

I agree, I think there are some issues, or at least limitations, associated with the SRC using SSRC multiplexing.

> - Do you really mean a unique SSRC within the *RS*???

Yes, that is what I was proposing as a way to deal with it.

>    these problems. Maybe it just needs to be used here too.)

If each CS is in a unique m-line and there is no multiplexing of RTP sessions across multiple m-lines, then the SSRCs need only be unique per CS.
In my description, I was assuming a single m-line with one or more CSs being multiplexed.

>    won't be possible. If so, I guess it should be mentioned.

Exactly, this is why I added the statement:
   The CNAMEs used
   in the CSs are not preserved within the RS.  The SRS relies on the
   SIPREC metadata to determine the participants included within each
   multiplexed stream."
 
> need be REQUIRED to convey this much info.)

I agree, we need more work on this. My underlying goal to convey as much in SDP, RTP, RTCP as possible and have metadata fill in the gaps.

Cheers,
Charles
 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 30 Jul 2012 12:28:17 -0700

Hi Paul,

Please see inline.

Henry

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: July-26-12 4:32 PM
> To: [email-masked]
> In general, I think we need some discussion of what should happen if 
> RTP stream multiplexing is being used within a single CS RTP session. 
> ISTM that there should be a way for the SRC to convey enough info to 
> the SRS so that it can understand how RTP streams were / weren't 
> multiplexed in the CS and so reconstruct things properly. (OTOH I 
> don't think the SRC need be REQUIRED to convey this much info.)
> 
> Section 9.1:
> 

> data, such as sessions that were previously active but that have
ended.
[Henry] I agree clarity is important here; will update the wording to
reflect this point. 

> in the Accept. (Its only *sent*, not *received*.)
[Henry] Thanks for catching this.

> This seems wrong. Fix it by: s/without/with/
[Henry] Oops! Thanks for catching this!

> means lack of preference.

[Henry] I too had a bit of trouble when I was writing this statement to
define the behaviour for omission. It makes sense that in the case of
3pcc then we cannot guarantee that the preference can be remembered. I
am okay to treat omission as no preference stated.