Subject: [siprec] summary of changes for draft-portman-siprec-protocol-04

From: "Henry Lum" <[email-masked]>
Date: Sun, 1 May 2011 20:09:01 -0700

Hi,

I want to summarize the list of changes we are planning to include in
the next revision of the document:

-          Remove use of INFO

-          Both INVITE or UPDATE can be used for metadata transport
through content-disposition

-          Recording indication is placed at SDP media level

-          Recording awareness is indicated at SIP level with options;
feature tag was also considered

-          Recording preference is placed at SDP media level

-          RTP model discussion and time synchronization; so far we seem
to agree to handle different RTP models rather than requiring a single
model. There are 3 models we have identified so far:

o   RTP mixer - SRC mixes media streams and can directly synchronize
timestamps with metadata and also generate RTCP

o   RTP translator - Media streams are simply forwarded to the SRS by
the SRC. SRC is only capable to indicating start/stop times to the SRS
in metadata.

o   RTP endpoint (is that the right term?) - SRC is neither a mixer nor
translator, but is capable of rewriting RTP and RTCP in order to
synchronize on the timestamps with metadata.

Regards,

Henry

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 May 2011 18:43:49 +0200

Henry,

Concerning the RTP model, I agree that the consensus to date seems to be to cover different RTP models, but I feel we should get something into the architecture draft to start with, and then later see whether there is any impact on the protocol draft.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 02 May 2011 04:09
> To: [email-masked]
> Subject: [siprec] summary of changes for 
> draft-portman-siprec-protocol-04
> 
> Hi,
> 
>  
> 
> I want to summarize the list of changes we are planning to 
> include in the next revision of the document:
> 
>  
> 
> -          Remove use of INFO
> 
> -          Both INVITE or UPDATE can be used for metadata 
> transport through content-disposition
> 
> -          Recording awareness is indicated at SIP level with 
> options; feature tag was also considered
> 
> -          RTP model discussion and time synchronization; so 
> far we seem to agree to handle different RTP models rather 
> than requiring a single model. There are 3 models we have 
> identified so far:
> 
> o   RTP mixer - SRC mixes media streams and can directly 
> synchronize timestamps with metadata and also generate RTCP
> 
> o   RTP translator - Media streams are simply forwarded to 
> the SRS by the SRC. SRC is only capable to indicating 
> start/stop times to the SRS in metadata.
> 
> o   RTP endpoint (is that the right term?) - SRC is neither a 
> mixer nor translator, but is capable of rewriting RTP and 
> RTCP in order to synchronize on the timestamps with metadata.
> 
>  
> 
> Regards,
> 
> Henry
> 
>  
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities. 
>

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 3 May 2011 11:18:21 -0700

Hi John,

Okay, let's discuss this topic further in the interim meeting to
determine whether there is any need to specify any protocol related
changes.

Regards,
Henry

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, May 03, 2011 12:44 PM
> To: Henry Lum; [email-masked]
> Subject: RE: summary of changes for draft-portman-siprec-protocol-04
> 
> Henry,
> 
> Concerning the RTP model, I agree that the consensus to date seems to
> be to cover different RTP models, but I feel we should get something
> into the architecture draft to start with, and then later see whether
> there is any impact on the protocol draft.
> 
> John
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 4 May 2011 16:16:58 -0700

I intended to put together a draft covering RTP recommendations and
models. Unfortunately, I did not have enough bandwidth to get this done
in time for the interim meeting. Instead, I have attached my thoughts to
get some feedback. I would be happy to continue work in this area if
people think it is useful. 

-------------------
Version 0.2
April 26, 2011

(1) Introduction

This document provides recommendations and guidelines for RTP and RTCP
in the context of SIPREC. In order to communicate most effectively, the
Session Recording Client (SRC) and the Session Recording (SRS) should
utilize the mechanisms provided by RTP in a well defined and predicable
manner. It is the goal of this document to make the reader aware of
these mechanisms and provide recommendations and guidelines. This
document is completely informational. It includes no requirements and no
normative language. 

(2) Definitions

This document uses the definitions provided in
draft-ietf-siprec-architecture for all SIPREC modules. A Session
Recording Client (SRC), as defined within SIPREC, is expected to
implement one or more of a variety of RTP roles within the context of
various SIPREC use cases. These roles include, but are not limited to,
acting as an end system, a mixer, or a translator. This document uses
the definitions provided in "RTP: A Transport Protocol for Real-Time
Application" [RFC 3550] for these roles. 

(3) RTCP

The RTP data transport is augmented by a control protocol (RTCP) to
allow monitoring of the data delivery. RTCP, as defined in [RFC3550], is
based on the periodic transmission of control packets to all
participants in the RTP session, using the same distribution mechanism
as the data packets. 
Support for RTCP is recommended as it provides, among other things, the
following important functionality in relation to SIPREC:

1) Feedback on the quality of the data distribution. This feedback is
important for flow and congestion control functions, and to get feedback
from the receivers to diagnose faults in the distribution. As such, RTCP
is a well defined and efficient mechanism for the SRS to inform the SRC
or any issues that arise in the reception of media that is to be
recorded. 

2) Carries a persistent transport-level identifier for an RTP source
called the canonical name or CNAME. The SSRC identifier may change if a
conflict is discovered or a program is restarted; in which case
receivers can use the CNAME to keep track of each participant.
Receivers may also use the CNAME to associate multiple data streams from
a given participant in a set of related RTP sessions, for example to
synchronize audio and video. Synchronization of media streams is also
facilitated by the NTP and RTP timestamps included in RTCP packets by
data senders.

(4) RTP Profile

The recommended RTP profiles for both the SRC and SRS are "Extended
Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based
Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and
"Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non encrypted
media streams. However, as this is not a requirement, some
implementations may use "The Secure Real-time Transport Protocol
(SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences
with Minimal Control", AVP [RFC 3551]. Therefore, it is recommended that
the SRC and SRS not rely entirely on SAVPF or AVPF for core
functionality that may be at least partially achievable using SAVP and
AVP.

AVPF and SAVPF provide an improved RTCP timer model that allows more
flexible transmission of RTCP packets as response to events, rather than
strictly according to bandwidth.
SAVP and SAVPF provide media encryption, integrity protection, replay
protection, and a limited form of source authentication. They do not
contain or require a specific keying mechanism.

(5) SRSC

The synchronization source (SSRC), as defined in [RFC3550], is carried
in the RTP header and in various fields of RTCP packets. It is a random
32-bit number that is required to be globally unique within an RTP
session.  It is crucial that the number be chosen with care in order
that participants on the same network or starting at the same time are
not likely to choose the same number. Guidelines regarding SSRC value
selection and conflict resolution are provided in [RFC3550].

The SSRC may also be used to separate different sources of media within
a single RTP session. For this reason as well as for conflict
resolution, it is important that the SRC and SRC handle changes in SSRC
values and properly identify the reason of the change. The CNAME values
carried in RTCP facilitate this identification.

(6) CSRC

The contributing source (CSRC), as defined in [RFC3550], identifies the
source of a stream of RTP packets that has contributed to the combined
stream produced by an RTP mixer. The mixer inserts a list of the SSRC
identifiers of the sources that contributed to the generation of a
particular packet into the RTP header of that packet. This list is
called the CSRC list. It is recommended that a SRC, when acting a mixer,
sets the CSRC list accordingly, and that the SRS interprets the CSRC
list appropriately when received.

(7) SDES

The Source Description (SDES), as defined in [RFC3550], contains an
SSRC/CSRC identifier followed by a list of zero or more items, which
carry information about the SSRC/CSRC. End systems send one SDES packet
containing their own source identifier (the same as the SSRC in the
fixed RTP header).  A mixer sends one SDES packet containing a chunk for
each contributing source from which it is receiving SDES information, or
multiple complete SDES packets.

(8) CNAME

The Canonical End-Point Identifier (CNAME), as defined in [RFC3550],
provide the binding from the SSRC  identifier to an identifier for the
source (sender or receiver)  that remains constant. It is important the
an SRC and SRS generate CNAMEs appropriately and use them for this
purpose. Guidelines for generating CNAME values are provided in
"Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)" [RFC6222].

(9) Keepalive

It is anticipated that media streams in SIPREC may exist in inactive
states for extended periods of times for an of a number of valid
reasons. In order to the bindings and any pinholes in NATs/firewalls to
remain active during such intervals, it is recommended to follow the
keep-alive procedures in "Application Mechanism for keeping alive the
Network Address Translator             
(NAT) mappings associated to RTP/RTCP flows",
[draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. 

(10) RTCP Feedback Messages

"Codec Control Messages in the RTP Audio-Visual Profile with Feedback
(AVPF)" [RFC 5104] specifies extensions to the messages defined in AVPF
[RFC4585]. Support for and proper usage of these messages is important
to SRC and SRS implementations.

(10.1) Full Intra Request 

A Full Intra Request (FIR) Command, when received by the designate media
sender, requires that the media sender sends a Decoder Refresh Point at
the earliest opportunity. Using a decoder refresh point implies
refraining from using any picture sent prior to that point as a
reference for the encoding process of any subsequent picture sent in the
stream.

Decoder refresh points, especially Intra or IDR pictures for H.264 video
codecs, are in general several times larger in size than predicted
pictures. Thus, in scenarios in which the available bit rate is small,
the use of a decoder refresh point implies a delay that is significantly
longer than the typical picture duration.

(10.1.1) SIP INFO for FIR

"XML Schema for Media Control" [RFC5168] defines an Extensible Markup
Language (XML) Schema for video fast update. Implementations are
discouraged from using the method described except for backward
compatibility purposes. Implementations should use FIR messages, as
described in (10.1) instead.

(10.2) Picture Loss Indicator
Using the FIR command to recover from errors is explicitly disallowed,
and instead the PLI message defined in AVPF [RFC4585] should be used.
The PLI message reports lost pictures and has been included in AVPF for
precisely that purpose.

(10.3) Temporary Maximum Media Stream Bit Rate Request

A receiver, translator, or mixer uses the Temporary Maximum Media Stream
Bit Rate Request (TMMBR) to request a sender to limit the maximum bit
rate for a media stream to the provided value. Appropriate use of TMMBR
facilitates rapid adaptation to changes in available bandwidth. 

(10.3.1) Renegotiation of SDP bandwidth attribute

If it is likely that the new value indicated by TMMBR will be valid for
the remainder of the session, the TMMBR sender is expected to perform a
renegotiation of the session upper limit using the session signaling
protocol. Therefore for SIPREC, implementations are recommended to use
TMMBR for temporary changes, and renegotiation of bandwidth via SDP
offer/answer of more permanent changes.

(11) Symmetric RTP/RTCP

Within the SDP offer/answer, RTP entities choose the RTP and RTCP
transport addresses (i.e., IP addresses and port numbers) on which to
receive packets. When sending RTP packets; however, they may use a
different IP address or port number for RTP, RTCP, or both.  Symmetric
RTP/RTCP requires that the IP address and port number for sending and
receiving RTP/RTCP packets are identical. Using Symmetric RTP and RTCP
[RFC4961] is recommended.

---------------------

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henry Lum
> Sent: Tuesday, May 03, 2011 11:18 AM
> To: Elwell, John; [email-masked]
> Subject: Re: [siprec] summary of changes for
> > > attachments belongs to Alcatel-Lucent and/or its affiliated
------------------------------------------------------------------------
------------------------------
> -------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary
> information of Alcatel-Lucent and/or its affiliated entities. Access
by the intended recipient only is
> authorized. Any liability arising from any party acting, or refraining
from acting, on any information
> contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the
> sender immediately, destroy the original transmission and its
attachments and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
the information in any medium.
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Thu, 5 May 2011 09:59:33 +0300

Charles Hi

I think it is very important and helpful.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Thursday, May 05, 2011 2:17 AM
To: Henry Lum; Elwell, John; [email-masked]
Subject: Re: [siprec] summary of changes for draft-portman-siprec-protocol-04

I intended to put together a draft covering RTP recommendations and models. Unfortunately, I did not have enough bandwidth to get this done in time for the interim meeting. Instead, I have attached my thoughts to get some feedback. I would be happy to continue work in this area if people think it is useful. 

-------------------
Version 0.2
April 26, 2011

(1) Introduction

This document provides recommendations and guidelines for RTP and RTCP in the context of SIPREC. In order to communicate most effectively, the Session Recording Client (SRC) and the Session Recording (SRS) should utilize the mechanisms provided by RTP in a well defined and predicable manner. It is the goal of this document to make the reader aware of these mechanisms and provide recommendations and guidelines. This document is completely informational. It includes no requirements and no normative language. 

(2) Definitions

This document uses the definitions provided in draft-ietf-siprec-architecture for all SIPREC modules. A Session Recording Client (SRC), as defined within SIPREC, is expected to implement one or more of a variety of RTP roles within the context of various SIPREC use cases. These roles include, but are not limited to, acting as an end system, a mixer, or a translator. This document uses the definitions provided in "RTP: A Transport Protocol for Real-Time Application" [RFC 3550] for these roles. 

(3) RTCP

The RTP data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery. RTCP, as defined in [RFC3550], is based on the periodic transmission of control packets to all participants in the RTP session, using the same distribution mechanism as the data packets. 
Support for RTCP is recommended as it provides, among other things, the following important functionality in relation to SIPREC:

1) Feedback on the quality of the data distribution. This feedback is important for flow and congestion control functions, and to get feedback from the receivers to diagnose faults in the distribution. As such, RTCP is a well defined and efficient mechanism for the SRS to inform the SRC or any issues that arise in the reception of media that is to be recorded. 

2) Carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. The SSRC identifier may change if a conflict is discovered or a program is restarted; in which case receivers can use the CNAME to keep track of each participant.
Receivers may also use the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. Synchronization of media streams is also facilitated by the NTP and RTP timestamps included in RTCP packets by data senders.

(4) RTP Profile

The recommended RTP profiles for both the SRC and SRS are "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", [RFC5124] when using encrypted RTP streams, and "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", [RFC4585] when using non encrypted media streams. However, as this is not a requirement, some implementations may use "The Secure Real-time Transport Protocol (SRTP)", [RFC 3711] and "RTP Profile for Audio and Video Conferences with Minimal Control", AVP [RFC 3551]. Therefore, it is recommended that the SRC and SRS not rely entirely on SAVPF or AVPF for core functionality that may be at least partially achievable using SAVP and AVP.

AVPF and SAVPF provide an improved RTCP timer model that allows more flexible transmission of RTCP packets as response to events, rather than strictly according to bandwidth.
SAVP and SAVPF provide media encryption, integrity protection, replay protection, and a limited form of source authentication. They do not contain or require a specific keying mechanism.

(5) SRSC

The synchronization source (SSRC), as defined in [RFC3550], is carried in the RTP header and in various fields of RTCP packets. It is a random 32-bit number that is required to be globally unique within an RTP session.  It is crucial that the number be chosen with care in order that participants on the same network or starting at the same time are not likely to choose the same number. Guidelines regarding SSRC value selection and conflict resolution are provided in [RFC3550].

The SSRC may also be used to separate different sources of media within a single RTP session. For this reason as well as for conflict resolution, it is important that the SRC and SRC handle changes in SSRC values and properly identify the reason of the change. The CNAME values carried in RTCP facilitate this identification.

(6) CSRC

The contributing source (CSRC), as defined in [RFC3550], identifies the source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer. The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. It is recommended that a SRC, when acting a mixer, sets the CSRC list accordingly, and that the SRS interprets the CSRC list appropriately when received.

(7) SDES

The Source Description (SDES), as defined in [RFC3550], contains an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header).  A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets.

(8) CNAME

The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], provide the binding from the SSRC  identifier to an identifier for the source (sender or receiver)  that remains constant. It is important the an SRC and SRS generate CNAMEs appropriately and use them for this purpose. Guidelines for generating CNAME values are provided in "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222].

(9) Keepalive

It is anticipated that media streams in SIPREC may exist in inactive states for extended periods of times for an of a number of valid reasons. In order to the bindings and any pinholes in NATs/firewalls to remain active during such intervals, it is recommended to follow the keep-alive procedures in "Application Mechanism for keeping alive the
Network Address Translator             
(NAT) mappings associated to RTP/RTCP flows", [draft-ietf-avt-app-rtp-keepalive] for all RTP media streams. 

"Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)" [RFC 5104] specifies extensions to the messages defined in AVPF [RFC4585]. Support for and proper usage of these messages is important to SRC and SRS implementations.

A Full Intra Request (FIR) Command, when received by the designate media sender, requires that the media sender sends a Decoder Refresh Point at the earliest opportunity. Using a decoder refresh point implies refraining from using any picture sent prior to that point as a reference for the encoding process of any subsequent picture sent in the stream.

Decoder refresh points, especially Intra or IDR pictures for H.264 video codecs, are in general several times larger in size than predicted pictures. Thus, in scenarios in which the available bit rate is small, the use of a decoder refresh point implies a delay that is significantly longer than the typical picture duration.

"XML Schema for Media Control" [RFC5168] defines an Extensible Markup Language (XML) Schema for video fast update. Implementations are discouraged from using the method described except for backward compatibility purposes. Implementations should use FIR messages, as described in (10.1) instead.

(10.2) Picture Loss Indicator
Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used.
The PLI message reports lost pictures and has been included in AVPF for precisely that purpose.

A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bit Rate Request (TMMBR) to request a sender to limit the maximum bit rate for a media stream to the provided value. Appropriate use of TMMBR facilitates rapid adaptation to changes in available bandwidth. 

If it is likely that the new value indicated by TMMBR will be valid for the remainder of the session, the TMMBR sender is expected to perform a renegotiation of the session upper limit using the session signaling protocol. Therefore for SIPREC, implementations are recommended to use TMMBR for temporary changes, and renegotiation of bandwidth via SDP offer/answer of more permanent changes.

(11) Symmetric RTP/RTCP

Within the SDP offer/answer, RTP entities choose the RTP and RTCP transport addresses (i.e., IP addresses and port numbers) on which to receive packets. When sending RTP packets; however, they may use a different IP address or port number for RTP, RTCP, or both.  Symmetric RTP/RTCP requires that the IP address and port number for sending and receiving RTP/RTCP packets are identical. Using Symmetric RTP and RTCP [RFC4961] is recommended.

---------------------

Cheers,
Charles

Behalf Of Henry Lum
> > > I want to summarize the list of changes we are planning to include 
> > > in the next revision of the document:
> > >
> > >
> > >
> > > -          Remove use of INFO
> > >
> > > far we seem to agree to handle different RTP models rather than 
> > > requiring a single model. There are 3 models we have identified so 
> > > far:
> > >
> > > the SRS by the SRC. SRC is only capable to indicating start/stop 
> > > times to the SRS in metadata.
> > >
> > > mixer nor translator, but is capable of rewriting RTP and RTCP in 
> > > order to synchronize on the timestamps with metadata.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Henry
> > >
> > >
> > >
> > >
> > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may 
> > > contain confidential and proprietary information of Alcatel-Lucent 
> > > and/or its affiliated entities. Access by the intended recipient 
> > > only is authorized. Any liability arising from any party acting, 
> > > or refraining from acting, on any information contained in this 
> > > e-mail is hereby excluded. If you are not the intended recipient, 
> > > please notify the sender immediately, destroy the original 
> > > transmission and its attachments and do not disclose the contents 
> > > to any other person, use it for any purpose, or store or copy the

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 May 2011 16:10:55 +0200

Hi All,

Regarding the RTP model I have been preparing text for the architecture draft which is I think the place to document this as I am not aware of any protocol extensions that are needed. 

My draft text for the architecture document will follow in my next e-mail.

Regards
Andy

> Sent: 03 May 2011 19:18
> --------------------------------------------------------------
> -----------------------------------------------------

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 6 May 2011 08:41:02 +0200

Charles,

Thanks for producing this. I see that Andy has also proposed some text on RTP, although there is very little overlap between the two. Perhaps the two of you can work on a merged proposal.

As has been stated before, I think we want to see some or all of this material in the architecture document, although if we need any normative material (e.g., on recommending profiles), that would probably need to go into the protocol document (the architecture document is only Informational).

But I think the first thing to do is get some sort of consensus on what we want to say. If producing an additional individual draft as an interim placeholder is the pragmatic way to do it, fine. In any case, we should certainly try to have some discussions on these points on Monday's call - if you wish I could let you lead that discussion (say 15 minutes, stealing from each of the other slots). Let me know.

John (as chair)

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 05 May 2011 00:17
> Subject: RE: [siprec] summary of changes for
> ----------
> may contain

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 6 May 2011 08:43:06 +0200

Charles

I won't comment in detail on your text, but a couple of small points:

1. What is meant by "Support for RTCP is recommended"? RTCP is already mandated in RFC 3550, so we can't soften that. I know in practice some implementations don't support it, but I don't think we can go against RFC 3550.

2. AVPF and SAVPF are recommended, with the ability to fall back to AVP or SAVP. It would be good to have some rationale as to why SIPREC merits recommending AVPF and SAVPF. Currently the text states their advantages, but doesn't explain why these advantages are particularly important for SIPREC.

3. "Using the FIR command to recover from errors is explicitly disallowed,
and instead the PLI message defined in AVPF [RFC4585] should be used.
The PLI message reports lost pictures and has been included in AVPF for
precisely that purpose."
This presumably applies only if AVPF/SAVPF is used.

4. The text on symmetric RTP/RTCP seems to mix up the symmetric RTP/RTCP principle (use of same port/address for transmitting and receiving) and the RTP/RTCP multiplexing concept (RTP and RTCP on the same port). Perhaps the two should be separated.

John (as individual)

> From: Elwell, John
> Sent: 06 May 2011 07:41
> To: 'Charles Eckel (eckelcu)'; Henry Lum; [email-masked]
> Subject: RTP Recommendations (was RE: [siprec] summary of
> changes for draft-portman-siprec-protocol-04)
>
> Charles,
>
> Thanks for producing this. I see that Andy has also proposed
> some text on RTP, although there is very little overlap
> between the two. Perhaps the two of you can work on a merged proposal.
>
> As has been stated before, I think we want to see some or all
> of this material in the architecture document, although if we
> need any normative material (e.g., on recommending profiles),
> that would probably need to go into the protocol document
> (the architecture document is only Informational).
>
> But I think the first thing to do is get some sort of
> consensus on what we want to say. If producing an additional
> individual draft as an interim placeholder is the pragmatic
> way to do it, fine. In any case, we should certainly try to
> have some discussions on these points on Monday's call - if
> you wish I could let you lead that discussion (say 15
> minutes, stealing from each of the other slots). Let me know.
>
> John (as chair)
>
> > > > Concerning the RTP model, I agree that the consensus to
> date seems
> > to

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 6 May 2011 10:22:34 -0700

Sounds good. I am not sure if I will find time to put any slides
together by the end of today, but worst case we can walk through the
e-mails.
15 minutes is great.

Cheers,
Charles

> Sent: Thursday, May 05, 2011 11:41 PM
> To: Charles Eckel (eckelcu); Henry Lum; [email-masked]
> Subject: RTP Recommendations (was RE: [siprec] summary of changes for
draft-portman-siprec-protocol-
> 04)
> 
> Charles,
> 
> Thanks for producing this. I see that Andy has also proposed some text
on RTP, although there is very
> little overlap between the two. Perhaps the two of you can work on a
merged proposal.
> 
> As has been stated before, I think we want to see some or all of this
material in the architecture
> document, although if we need any normative material (e.g., on
recommending profiles), that would
> probably need to go into the protocol document (the architecture
document is only Informational).
> 
> But I think the first thing to do is get some sort of consensus on
what we want to say. If producing
> an additional individual draft as an interim placeholder is the
pragmatic way to do it, fine. In any
> case, we should certainly try to have some discussions on these points
on Monday's call - if you wish
> I could let you lead that discussion (say 15 minutes, stealing from
each of the other slots). Let me
> know.
> > > > Concerning the RTP model, I agree that the consensus to date
seems

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 6 May 2011 15:24:24 -0700

> Sent: Thursday, May 05, 2011 11:43 PM
> Subject: RE: RTP Recommendations (was RE: [siprec] summary of changes
for draft-portman-siprec-
> protocol-04)
> 1. What is meant by "Support for RTCP is recommended"? RTCP is already
mandated in RFC 3550, so we
> can't soften that. I know in practice some implementations don't
support it, but I don't think we can
> go against RFC 3550.

I always felt RTCP was required as well, but when challenged on that, I
was not able to see where in RFC 3550 it is stated as mandatory. Looking
more closely at RFC 3550, I think the following text in section 6 does
mandate RTCP, "The first two functions require that all participants
send RTCP packets, therefore the rate must be controlled in order for
RTP to scale up to a large number of participants."
Armed with this, I agree completely with your comment. For now, I will
update that, and we can decide later if it simply want to remove that
section as unnecessary.
 
> 2. AVPF and SAVPF are recommended, with the ability to fall back to
AVP or SAVP. It would be good to
> have some rationale as to why SIPREC merits recommending AVPF and
SAVPF. Currently the text states
> their advantages, but doesn't explain why these advantages are
particularly important for SIPREC.

Will add this.

> This presumably applies only if AVPF/SAVPF is used.

Correct. Will clarify this.

> 4. The text on symmetric RTP/RTCP seems to mix up the symmetric
RTP/RTCP principle (use of same
> port/address for transmitting and receiving) and the RTP/RTCP
multiplexing concept (RTP and RTCP on
> the same port). Perhaps the two should be separated.
>

Will do.

Thanks,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 6 May 2011 16:27:01 -0700

The attached document addresses the comments provided by John and
includes a copy/paste of the RTP models provided by Andy. I have placed
them both within this single document to facilitate discussion in
Monday's session. What we actually want to say and how/where to arrange
it will be a subject of Monday's discussion.

Cheers,
Charles 

> From: Charles Eckel (eckelcu)
> Sent: Friday, May 06, 2011 10:23 AM
> To: 'Elwell, John'; Henry Lum; [email-masked]
> Sounds good. I am not sure if I will find time to put any slides
together by the end of today, but
> worst case we can walk through the e-mails.
> 15 minutes is great.
> 
> Cheers,
> Charles
> 
> > Subject: RTP Recommendations (was RE: [siprec] summary of changes
for draft-portman-siprec-protocol-
> > 04)
> >
> > Charles,
> >
> > Thanks for producing this. I see that Andy has also proposed some
text on RTP, although there is
> very
merged proposal.
> >
> > As has been stated before, I think we want to see some or all of
this material in the architecture
> > case, we should certainly try to have some discussions on these
points on Monday's call - if you
> wish
seems

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 May 2011 19:29:17 -0400

Charles, John,

> update that, and we can decide later if it simply want to remove that

Disclaimers:

1) I know almost no details of RTP.
2) I've no axe to grind here one way or the other

I was curious and so I looked at the referenced section of 3550, just 
parsing it as a standards lawyer.

There a no normative terms in bullets 1-4 of Section 6.

The paragraph after them applies normative terms to them:

    Functions 1-3 SHOULD be used in all environments, but particularly in
    the IP multicast environment.  ...

I think that makes 1 & 2 non-required. The statement Charles quotes 
asserts that 1 & 2 require sending RTCP. But that is only meaningful 
*if* you are implementing 1 & 2, which is optional.

So, legalistically, it appears to me that use of RTCP can inferred to be 
only SHOULD strength, especially in a unicast environment.

	Thanks,
	Paul