Subject: [siprec] RTP model

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 10:05:25 +0200

There were discussions before and during the Prague meeting about multiplexing media streams from different participants on to the same port. It became apparent that we need a better understanding of the RTP model we are using first, before we can answer this.

The question is whether the SRC acts as a translator or as a mixer or end system.

A translator is defined in RFC 3550 as:
"An intermediate system that forwards RTP packets
      with their synchronization source identifier intact.  Examples of
      translators include devices that convert encodings without mixing,
      replicators from multicast to unicast, and application-level
      filters in firewalls."

A mixer or end system, in contrast, would assign new synchronisation sources to RTP packets.

The translator model seems to require less processing in the SRC - RTP packets would just be forwarded unchanged to the SRC (i.e., the UDP packet would change but its RTP payload would be unchanged).

However, the translator model prevents some capabilities, e.g.:
- the SRC cannot transcode (e.g., if the SRS does not support the codec used in the CS);
- the SRC cannot mix streams from different participants (e.g., to reduce the bandwidth required on the RS path);
- the SRC cannot encrypt streams on the RS path if unencrypted on the CS path or vice versa;
- the SRC cannot use different encryption keys on the CS path and the RS path.

Therefore, although the translator model might work in some situations, it probably can't satisfy all requirements.

Also with the translator model, we would need to be clear how RTCP would work. Consider an SRC at a B2BUA. It receives RTP packets from party A, forwards them as a translator to party B, and also forwards them as a translator to the SRS. The SRC will receive RTCP packets from both party B and the SRS and needs to send RTCP packets to party A - how does the SRC handle this?

John (as individual)

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 6 Apr 2011 15:16:18 +0530

Except for mixing, the translator model doesn't prevent the SRC from
transcoding or encrypting or using different encryption keys for the CS
and RS. RFC 5117 describes different kinds of translators and this is
what it says about media translators:

<snip>
Media Translators (Topo-Media-Translator), in contrast, modify the media
stream itself.  This process is commonly known as transcoding. The
modification of the media stream can be as small as removing parts of
the stream, and it can go all the way to a full transcoding (down to the
sample level or equivalent) utilizing a different media codec. Media
Translators are commonly used to connect entities without a common
interoperability point.
</snip>

However, I agree RTCP processing at SRC needs more thought if it were a
translator and some of the guidelines are described in section 7.2 of
RFC 3550. For e.g, while the SRC may want to forward the SDES
information to the SRS for it to correlate it with the participant
information delivered in metadata, it may need to modify the SR
information like byte count, packet count etc, since what it may send to
the SRS might be different from what is may receive from the
participants.

The general rule specified in RFC 3550 is to do what makes sense for a
particular translation. So, we could come up our own guidelines when the
SRC is a translator, depending on what makes sense for media recording.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
|Sent: Wednesday, April 06, 2011 1:35 PM
|To: [email-masked]
|Subject: [siprec] RTP model
|
|There were discussions before and during the Prague meeting about
multiplexing media streams from
|different participants on to the same port. It became apparent that we
need a better understanding of
|the RTP model we are using first, before we can answer this.
|
|The question is whether the SRC acts as a translator or as a mixer or
end system.
|
|A translator is defined in RFC 3550 as:
|"An intermediate system that forwards RTP packets
|      with their synchronization source identifier intact.  Examples of
|      translators include devices that convert encodings without
mixing,
|      replicators from multicast to unicast, and application-level
|      filters in firewalls."
|
|A mixer or end system, in contrast, would assign new synchronisation
sources to RTP packets.
|
|The translator model seems to require less processing in the SRC - RTP
packets would just be forwarded
|unchanged to the SRC (i.e., the UDP packet would change but its RTP
payload would be unchanged).
|
|However, the translator model prevents some capabilities, e.g.:
|- the SRC cannot transcode (e.g., if the SRS does not support the codec
used in the CS);
|- the SRC cannot mix streams from different participants (e.g., to
reduce the bandwidth required on
|the RS path);
|- the SRC cannot encrypt streams on the RS path if unencrypted on the
CS path or vice versa;
|- the SRC cannot use different encryption keys on the CS path and the
RS path.
|
|Therefore, although the translator model might work in some situations,
it probably can't satisfy all
|requirements.
|
|Also with the translator model, we would need to be clear how RTCP
would work. Consider an SRC at a
|B2BUA. It receives RTP packets from party A, forwards them as a
translator to party B, and also
|forwards them as a translator to the SRS. The SRC will receive RTCP
packets from both party B and the
|SRS and needs to send RTCP packets to party A - how does the SRC handle
this?
|
|John (as individual)
|
|
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2011 09:56:43 -0400

I am definitely not an expert on this subject, but ISTM that making a 
choice about one of these models would inordinately limit implementation 
choices for the SRC. IMO we want to provide a lot of latitude for SRC 
implementation, even if it means complicating life for the SRS.

	Thanks,
	Paul

On 4/6/2011 4:05 AM, Elwell, John wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 6 Apr 2011 20:27:19 +0530

I agree we should keep the models open to cater to different use-cases.
However, for the most common ones we anticipate, I think we should have
clear guidelines/recommendations on how it must/should/may work to
achieve basic interop among implementations of that model. For e.g, the
translator model for SRC looks a simple one that would cater to a large
number of cases and we might want to have clear
guidelines/recommendations on how RTP and RTCP should be handled for it.

thanks,
Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
|Sent: Wednesday, April 06, 2011 7:27 PM
|To: [email-masked]
|Subject: Re: [siprec] RTP model
|
|I am definitely not an expert on this subject, but ISTM that making a
|choice about one of these models would inordinately limit
implementation
|choices for the SRC. IMO we want to provide a lot of latitude for SRC
|implementation, even if it means complicating life for the SRS.
|
|	Thanks,
|	Paul
|
|On 4/6/2011 4:05 AM, Elwell, John wrote:
|> There were discussions before and during the Prague meeting about
multiplexing media streams from
|different participants on to the same port. It became apparent that we
need a better understanding of
|the RTP model we are using first, before we can answer this.
|>
|> The question is whether the SRC acts as a translator or as a mixer or
end system.
|>
|> A translator is defined in RFC 3550 as:
|> "An intermediate system that forwards RTP packets
|>        with their synchronization source identifier intact.  Examples
of
|>        translators include devices that convert encodings without
mixing,
|>        replicators from multicast to unicast, and application-level
|>        filters in firewalls."
|>
|> A mixer or end system, in contrast, would assign new synchronisation
sources to RTP packets.
|>
|> The translator model seems to require less processing in the SRC -
RTP packets would just be
|forwarded unchanged to the SRC (i.e., the UDP packet would change but
its RTP payload would be
|unchanged).
|>
|> However, the translator model prevents some capabilities, e.g.:
|> - the SRC cannot transcode (e.g., if the SRS does not support the
codec used in the CS);
|> - the SRC cannot mix streams from different participants (e.g., to
reduce the bandwidth required on
|the RS path);
|> - the SRC cannot encrypt streams on the RS path if unencrypted on the
CS path or vice versa;
|> - the SRC cannot use different encryption keys on the CS path and the
RS path.
|>
|> Therefore, although the translator model might work in some
situations, it probably can't satisfy
|all requirements.
|>
|> Also with the translator model, we would need to be clear how RTCP
would work. Consider an SRC at a
|B2BUA. It receives RTP packets from party A, forwards them as a
translator to party B, and also
|forwards them as a translator to the SRS. The SRC will receive RTCP
packets from both party B and the
|SRS and needs to send RTCP packets to party A - how does the SRC handle
this?
|>
|> John (as individual)
|>
|>
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|>
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2011 17:51:07 -0400

> guidelines/recommendations on how RTP and RTCP should be handled for it.

I don't know a lot about RTP, but the above seems right to me - each 
different way the SRC might relate to the RTP will need some specification.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 8 Apr 2011 19:17:08 +0530

I'm not RTP guy but I'm writing the mail based on SIPREC understanding.
In terms of SIPRC, SRC may be one of the following combination as per
the architecture

1) UA(CS) + UA (RS)
2) B2BUA (CS) + UA(RS)
3) focus (CS) + UA (RS)
4) Non-SIP to UA(CS) + UA(RS). Non-sip may be PSTN, H.323, Jingle,
RTCweb etc.,
5) Non-SIP to Non-SIP (CS) + UA(RS) - different permutation &
combination possible here 

IMO, SRC MAY support any of the RTP model like RTP translator, RTP mixer
or RTP endpoint and there is no restriction specific to SIPREC. How CS
RTP information passes to RS RTP is implementation specific. Say one SRC
which has (B2BUA + UA)  may prefer to acts as RTP translator
(forwarding) towards RS session whereas another SRC which has (B2BUA +
UA) may prefer to RTP Endpoint towards RS Session. Till now, we haven't
come across any restriction in RTP model specific to SIPREC.

The question raised in IETF-80 is "multiple stream in single port" usage
w.r.t metadata format. Here there two usecase:

1) "multiple stream in single port" for each participant (individually)
-  Here multiple stream     is related to multiple sources of stream
which has different SSRC but it belongs to single participant. It is
possible for SRC to act as RTP translator (forwarder) in case SRC is a
middle box (B2BUA, SBC)

2) "multiple stream in single port" for multiple participants - Here SRC
has to combine all stream from different participant together whereas
SRC has to act as RTP Endpoint. Please correct me incase I missed
understand the translator functionality. Please note that it is SRC
implementation choice. There is no need of restricting this stuff but I
really don't know the reason for doing this by SRC.

SRS is RTP Endpoint which store or perform real-time analysis of
RTP/RTCP packet instead of play in the endpoint. Here, I like to hear
from folks that any more restriction above RFC 3550 is required which is
specific to SIPREC.

Thanks
Partha  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat (pkyzivat)
Sent: Thursday, April 07, 2011 3:21 AM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [siprec] RTP model

On 4/6/2011 10:57 AM, Muthu ArulMozhi Perumal (mperumal) wrote:
> However, for the most common ones we anticipate, I think we should 
> have clear guidelines/recommendations on how it must/should/may work 
> to achieve basic interop among implementations of that model. For e.g,

> the translator model for SRC looks a simple one that would cater to a 
> large number of cases and we might want to have clear 

I don't know a lot about RTP, but the above seems right to me - each
different way the SRC might relate to the RTP will need some
specification.

	Thanks,
	Paul

> |different participants on to the same port. It became apparent that 
> |we
> |>  The question is whether the SRC acts as a translator or as a mixer

> |> or
> |>         with their synchronization source identifier intact.  
> |> Examples
> of
> |>  A mixer or end system, in contrast, would assign new 
> |> synchronisation
> sources to RTP packets.
> |>
> |>  - the SRC cannot encrypt streams on the RS path if unencrypted on 
> |> the
> CS path or vice versa;
> |>  - the SRC cannot use different encryption keys on the CS path and 
> |> the
> RS path.
> |>
> |SRS and needs to send RTCP packets to party A - how does the SRC 
> |handle
> this?
> |>
> |>  John (as individual)
> |>
> |>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 17:40:19 +0200

>From the various contributors do date on this thread, it sounds like people are in favour of some flexibility as to how the SRC behaves. I think we need something written down in the architecture document on this, enumerating the possibilities, perhaps in a new section, and it probably requires somebody with a reasonable understanding of RFC 3550 to do this. Any volunteers?

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 08 April 2011 14:47
> To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal)
> Cc: [email-masked]
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 8 Apr 2011 22:46:51 +0530

I volunteer to take this forward. Ram, Charles and I are having offline
discussions on this and we will get back with our thoughts to the group.

Muthu

|-----Original Message-----
|From: Elwell, John [mailto:[email-masked]]
|Sent: Friday, April 08, 2011 9:10 PM
|To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Muthu ArulMozhi
Perumal (mperumal)
|Cc: [email-masked]
|Subject: RE: [siprec] RTP model
|
|From the various contributors do date on this thread, it sounds like
people are in favour of some
|flexibility as to how the SRC behaves. I think we need something
written down in the architecture
|document on this, enumerating the possibilities, perhaps in a new
section, and it probably requires
|somebody with a reasonable understanding of RFC 3550 to do this. Any
volunteers?
|
|John
|
|> -----Original Message-----
|> From: [email-masked]
|> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
|> Sent: 08 April 2011 14:47
|> To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal)
|> Cc: [email-masked]
|> Subject: Re: [siprec] RTP model
|>
|> I'm not RTP guy but I'm writing the mail based on SIPREC
|> understanding.
|> In terms of SIPRC, SRC may be one of the following combination as per
|> the architecture
|>
|> 1) UA(CS) + UA (RS)
|> 2) B2BUA (CS) + UA(RS)
|> 3) focus (CS) + UA (RS)
|> 4) Non-SIP to UA(CS) + UA(RS). Non-sip may be PSTN, H.323, Jingle,
|> RTCweb etc.,
|> 5) Non-SIP to Non-SIP (CS) + UA(RS) - different permutation &
|> combination possible here
|>
|> IMO, SRC MAY support any of the RTP model like RTP
|> translator, RTP mixer
|> or RTP endpoint and there is no restriction specific to SIPREC. How
CS
|> RTP information passes to RS RTP is implementation specific.
|> Say one SRC
|> which has (B2BUA + UA)  may prefer to acts as RTP translator
|> (forwarding) towards RS session whereas another SRC which has (B2BUA
+
|> UA) may prefer to RTP Endpoint towards RS Session. Till now,
|> we haven't
|> come across any restriction in RTP model specific to SIPREC.
|>
|> The question raised in IETF-80 is "multiple stream in single
|> port" usage
|> w.r.t metadata format. Here there two usecase:
|>
|> 1) "multiple stream in single port" for each participant
|> (individually)
|> -  Here multiple stream     is related to multiple sources of stream
|> which has different SSRC but it belongs to single participant. It is
|> possible for SRC to act as RTP translator (forwarder) in case SRC is
a
|> middle box (B2BUA, SBC)
|>
|> 2) "multiple stream in single port" for multiple participants
|> - Here SRC
|> has to combine all stream from different participant together whereas
|> SRC has to act as RTP Endpoint. Please correct me incase I missed
|> understand the translator functionality. Please note that it is SRC
|> implementation choice. There is no need of restricting this
|> stuff but I
|> really don't know the reason for doing this by SRC.
|>
|> SRS is RTP Endpoint which store or perform real-time analysis of
|> RTP/RTCP packet instead of play in the endpoint. Here, I like to hear
|> from folks that any more restriction above RFC 3550 is
|> required which is
|> specific to SIPREC.
|>
|> Thanks
|> Partha
|>
|> -----Original Message-----
|> From: [email-masked]
|> [mailto:[email-masked]] On Behalf
|> Of Paul Kyzivat (pkyzivat)
|> Sent: Thursday, April 07, 2011 3:21 AM
|> To: Muthu ArulMozhi Perumal (mperumal)
|> Cc: [email-masked]
|> Subject: Re: [siprec] RTP model
|>
|>
|>
|> On 4/6/2011 10:57 AM, Muthu ArulMozhi Perumal (mperumal) wrote:
|> > I agree we should keep the models open to cater to different
|> use-cases.
|> > However, for the most common ones we anticipate, I think we should
|> > have clear guidelines/recommendations on how it
|> must/should/may work
|> > to achieve basic interop among implementations of that
|> model. For e.g,
|>
|> > the translator model for SRC looks a simple one that would
|> cater to a
|> > large number of cases and we might want to have clear
|> > guidelines/recommendations on how RTP and RTCP should be handled
for
|> it.
|>
|> I don't know a lot about RTP, but the above seems right to me - each
|> different way the SRC might relate to the RTP will need some
|> specification.
|>
|> 	Thanks,
|> 	Paul
|>
|> > thanks,
|> > Muthu
|> >
|> > |-----Original Message-----
|> > |From: [email-masked] [mailto:[email-masked]] On
|> > Behalf Of Paul Kyzivat (pkyzivat)
|> > |Sent: Wednesday, April 06, 2011 7:27 PM
|> > |To: [email-masked]
|> > |Subject: Re: [siprec] RTP model
|> > |
|> > |I am definitely not an expert on this subject, but ISTM
|> that making a
|>
|> > |choice about one of these models would inordinately limit
|> > implementation
|> > |choices for the SRC. IMO we want to provide a lot of
|> latitude for SRC
|>
|> > |implementation, even if it means complicating life for the SRS.
|> > |
|> > |	Thanks,
|> > |	Paul
|> > |
|> > |On 4/6/2011 4:05 AM, Elwell, John wrote:
|> > |>  There were discussions before and during the Prague
|> meeting about
|> > multiplexing media streams from
|> > |different participants on to the same port. It became
|> apparent that
|> > |we
|> > need a better understanding of
|> > |the RTP model we are using first, before we can answer this.
|> > |>
|> > |>  The question is whether the SRC acts as a translator or
|> as a mixer
|>
|> > |> or
|> > end system.
|> > |>
|> > |>  A translator is defined in RFC 3550 as:
|> > |>  "An intermediate system that forwards RTP packets
|> > |>         with their synchronization source identifier intact.
|> > |> Examples
|> > of
|> > |>         translators include devices that convert
|> encodings without
|> > mixing,
|> > |>         replicators from multicast to unicast, and
|> application-level
|> > |>         filters in firewalls."
|> > |>
|> > |>  A mixer or end system, in contrast, would assign new
|> > |> synchronisation
|> > sources to RTP packets.
|> > |>
|> > |>  The translator model seems to require less processing
|> in the SRC -
|> > RTP packets would just be
|> > |forwarded unchanged to the SRC (i.e., the UDP packet would
|> change but
|> > its RTP payload would be
|> > |unchanged).
|> > |>
|> > |>  However, the translator model prevents some capabilities, e.g.:
|> > |>  - the SRC cannot transcode (e.g., if the SRS does not
|> support the
|> > codec used in the CS);
|> > |>  - the SRC cannot mix streams from different
|> participants (e.g., to
|> > reduce the bandwidth required on
|> > |the RS path);
|> > |>  - the SRC cannot encrypt streams on the RS path if
|> unencrypted on
|> > |> the
|> > CS path or vice versa;
|> > |>  - the SRC cannot use different encryption keys on the
|> CS path and
|> > |> the
|> > RS path.
|> > |>
|> > |>  Therefore, although the translator model might work in some
|> > situations, it probably can't satisfy
|> > |all requirements.
|> > |>
|> > |>  Also with the translator model, we would need to be
|> clear how RTCP
|> > would work. Consider an SRC at a
|> > |B2BUA. It receives RTP packets from party A, forwards them as a
|> > translator to party B, and also
|> > |forwards them as a translator to the SRS. The SRC will receive
RTCP
|> > packets from both party B and the
|> > |SRS and needs to send RTCP packets to party A - how does the SRC
|> > |handle
|> > this?
|> > |>
|> > |>  John (as individual)
|> > |>
|> > |>
|> > |>  _______________________________________________
|> > |>  siprec mailing list
|> > |>  [email-masked]
|> > |>  https://www.ietf.org/mailman/listinfo/siprec
|> > |>
|> > |_______________________________________________
|> > |siprec mailing list
|> > [email-masked]
|> > |https://www.ietf.org/mailman/listinfo/siprec
|> >
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|>