Subject: [AVT] the use of "media sender SSRC" in draft-ietf-avt-rapid-acquisition-for-rtp-05

From: "Michael Lague (mlague)" <[email-masked]>
Date: Wed, 2 Dec 2009 10:00:08 -0600

I have some concerns regarding the requirements expressed in
draft-ietf-avt-rapid-acquisition-for-rtp-05 for the specification of the
"media sender SSRC" in out-of-band media descriptions.

The following text is included in the Introduction of
draft-ietf-avt-rapid-acquisition-for-rtp-05:

   ...It is also worth noting that in order to issue
   the initial RTCP message to the feedback target, the SSRC of the
   session to be joined must be known prior to any packet reception, and
   hence, needs to be signaled out-of-band (or otherwise communicated to
   the RTP receiver in advance of the initiation of the rapid
   acquisition operation).  In a Session Description Protocol (SDP)
   description, the SSRC MUST be signaled through the 'ssrc' attribute
   [I-D.ietf-avt-rtcpssm].

Similarly, Section 6.2 of the draft states (in item 1.):

       Before joining the primary multicast session, a new joining
       RTP_Rx learns the addresses associated with the new multicast
       session (addresses for the multicast source, group and
       retransmission server) by out-of-band means.  Also note that
       since no RTP packets have been received yet for this session, the
       SSRC must be obtained out-of-band.  See Section 8 for details.

And again, Section 8.2 of the draft states:

   When an RTP receiver requires rapid acquisition for a new multicast
   session it wants to join, it sends an RAMS-R message to the feedback
   target of that primary multicast session.  This feedback message has
   to have the SSRC of the primary multicast stream for which rapid
   acquisition is requested for.  However, since this RTP receiver has
   not received any RTP packets from the primary multicast session yet,
   the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
   of the media description [I-D.ietf-avt-rtcpssm].  In addition to the
   SSRC value, the 'cname' source attribute MUST also be present in the
   SDP description [RFC5576].

However, I would like to observe that 1) in many deployments, the system
hosting the Multicast Source is distinct from the system hosting the
Retransmission Server (as shown in Figure 1 of the draft); 2) existing
systems which provide a Multicast Source may not have the means to
provision SSRC values, but instead may generate random SSRC values, as
indicated in RFC 3550; 3) such systems often regenerate a new SSRC value
for a media stream, when the system restarts; and 4) in redundancy
schemes for such systems, if a backup component takes over for a failing
primary component, the SSRC values for the media streams may change. 

Thus in such deployments it may not be possible to provide accurate SSRC
values for media streams in the SDP descriptions provided out-of-band to
receiving clients. 

But it should also be noted that if feedback target transport addresses
are provisioned for the Retransmission Server in such a way that each
transport address uniquely identifies one and only one RTP stream, then
a receiving client need not have prior knowledge of the SSRC value for
the stream, in order to request its rapid acquisition.

Therefore I would like to request a change in the wording of the draft,
to provide for the possibility of requesting rapid acquisition of a
stream without prior knowledge of the its SSRC, in those cases where the
SSRC is not needed to uniquely identify the stream.

For example, the excerpt from the Introduction might be replaced with:

   ...It is also worth noting that in deployments where each feedback
target
   transport address may be associated with more than one RTP stream, 
   the SSRC of the session to be joined must be specified in the initial

   RTCP message to the feedback target prior to any packet reception,
and
   hence, needs to be signaled out-of-band (or otherwise communicated to
   the RTP receiver in advance of the initiation of the rapid
   acquisition operation).  In a Session Description Protocol (SDP)
   description, the SSRC MUST be signaled through the 'ssrc' attribute
   [I-D.ietf-avt-rtcpssm].

Similarly, the excerpt in section 6.2 might be replaced with:

       Before joining the primary multicast session, a new joining
       RTP_Rx learns the addresses associated with the new multicast
       session (addresses for the multicast source, group and
       retransmission server) by out-of-band means.  In deployments
       where each feedback target transport address does not uniquely
       identify a single RTP stream, the SSRC for the stream to be 
       acquired must also be obtained out-of-band, since no RTP packets 
       have been received yet for this session. See Section 8 for
details.

To clarify the message flow, the following might paragraph might be
inserted in item 2. of section 6.2., between the second and third
paragraphs:

    In deployments where each feedback target transport address of the
RS
    uniquely identifies a single RTP stream, the RS MAY ignore the media
    sender SSRC of the RAMS-R request, and may instead use the SSRC of
the
    RTP stream associated with the feedback target transport address on 
    which the request was received. In such deployments the 'ssrc'
attribute
    MAY be omitted from the media description which is conveyed
out-of-band
    to RTP receivers. However, if the transport address alone does not
uniquely
    identify a single RTP stream, and the media sender SSRC in the
request
    does not match any of the associated streams, then the RS must
ignore 
    the request.

And finally, the excerpt in Section 8.2 might be replaced with:

   When an RTP receiver requires rapid acquisition for a new multicast
   session it wants to join, it sends an RAMS-R message to the feedback
   target of that primary multicast session.  In deployments where each
   feedback target transport address is associated with only one RTP
stream,
   the RTP receiver does not need to learn the SSRC of the stream via an
   out-of-band method, and MAY specify zero for the media sender SSRC
(although
   zero is a valid SSRC value). In all other cases, the RAMS-R feedback
message 
   has to have the SSRC of the primary multicast stream for which rapid
   acquisition is requested.  However, since this RTP receiver has not 
   yet received any RTP packets from the primary multicast session, the
   RTP receiver MUST in this case learn the SSRC value from the 'ssrc' 
   Attribute of the media description [I-D.ietf-avt-rtcpssm].  In
addition 
   to the SSRC value, the 'cname' source attribute MUST also be present 
   in the SDP description [RFC5576].

--Mike Lague
  ([email-masked])

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 2 Dec 2009 11:17:53 -0500

Michael-

These are good points. I think these issues apply to the more general
RTCP feedback case, but we should be clear in our treatment of them in
RAMS.

To summarize your words (to be sure we are in the same page) --- For a
system that does not use the same 3-tuple for a feedback target address
for more than one stream, the SSRC is indeed not required in the RAMS-R.
For systems that do multiplex these feedback target addresses, a unique
SSRC is required to disambiguate the requests. If a unique SSRC is
required, the transition state from a given SSRC to another SSRC (for
instance, in the case of a component restart) may result in periods in
which RTCP feedback requests will be ambiguous.

The main effect of an SSRC changing in mid-stream would be that RTCP
feedback (and thus RAMS) would not work until the RTP-Rx and the RS
converge on a common SSRC.

The bulk of the proposed words seem reasonable at first glance. We do
need to consider whether to have the RS silently ignore the RAMS-R
request with an invalid SSRC or to send a reject message to the
originator.

Would it make sense to include a recommendation that systems that do not
have deterministic SSRCs use a single port per feedback target address?
This is really a RTP/RTCP concern, but I do not think this case is
covered in detail elsewhere.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Lague (mlague)
Sent: Wednesday, December 02, 2009 11:00 AM
To: [email-masked]
Cc: Rob Drisko (rdrisko)
Subject: [AVT] the use of "media sender SSRC"
indraft-ietf-avt-rapid-acquisition-for-rtp-05
Importance: Low

--Mike Lague
  ([email-masked])
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 2 Dec 2009 09:23:24 -0800

Some comments inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Ver Steeg
> (versteb)
> Sent: Wednesday, December 02, 2009 11:18 AM
> To: Michael Lague (mlague); [email-masked]
> Cc: Rob Drisko (rdrisko)
> Subject: Re: [AVT] the use of "media sender SSRC"indraft-ietf-avt-rapid-acquisition-for-
> rtp-05
> 
> Michael-
> 

The unique feature about RAMS is that we send feedback before we see a source packet. In regular feedback (such as NACK), the receiver already knows the SSRC of the source stream. So, this is not a concern.

> SSRC is required to disambiguate the requests. If a unique SSRC is

Exactly.

> which RTCP feedback requests will be ambiguous.

Which means RAMS will fail.
 
> converge on a common SSRC.

Yes.
 
> request with an invalid SSRC or to send a reject message to the

IMO, if the feedback target is solely serving for only one RTP stream, it should not care about the source SSRC in the received feedback messages.

Ow (meaning the feedback target is serving for more than one RTP streams), the requested SSRC must match to one of its streams. If it does not, FT silently drops the request.
 
> covered in detail elsewhere.

I largely discussed this issue in the draft-begen-avt-rams-scenarios draft. We also discussed this in MMUSIC in the last meeting. The comments we received were all saying that strict SSRC management across potentially a large number of sources was not feasible (or even possible) without a well-defined protocol for it.

So, I believe we need to make that recommendation. Does anybody think otherwise?

Mike's wording looks good to me.

-acbegen

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 2 Dec 2009 13:31:01 -0500

We are in agreement, with the possible exception of "silently drop". I
need to think about the relative merits of a RAMS-I with an error code
of BAD_SSRC.

Bvs

-----Original Message-----
From: Ali C. Begen (abegen) 
Sent: Wednesday, December 02, 2009 12:23 PM
To: Bill Ver Steeg (versteb); Michael Lague (mlague); [email-masked]
Cc: Rob Drisko (rdrisko)
Subject: RE: [AVT] the use of "media sender
SSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

Some comments inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bill Ver Steeg
> Subject: Re: [AVT] the use of "media sender
SSRC"indraft-ietf-avt-rapid-acquisition-for-
> RTCP feedback case, but we should be clear in our treatment of them in

The unique feature about RAMS is that we send feedback before we see a
source packet. In regular feedback (such as NACK), the receiver already
knows the SSRC of the source stream. So, this is not a concern.

Exactly.

 

Yes.
 
> request with an invalid SSRC or to send a reject message to the

IMO, if the feedback target is solely serving for only one RTP stream,
it should not care about the source SSRC in the received feedback
messages.

Ow (meaning the feedback target is serving for more than one RTP
streams), the requested SSRC must match to one of its streams. If it
does not, FT silently drops the request.
 
> covered in detail elsewhere.

I largely discussed this issue in the draft-begen-avt-rams-scenarios
draft. We also discussed this in MMUSIC in the last meeting. The
comments we received were all saying that strict SSRC management across
potentially a large number of sources was not feasible (or even
possible) without a well-defined protocol for it.

So, I believe we need to make that recommendation. Does anybody think
otherwise?

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 2 Dec 2009 10:38:41 -0800

I'd think in most of the cases such messages will be an attack. So, that's why I think the server should not respond.

Sending a "bad_ssrc" message will not help a legit client much. The client will time out eventually and join the multicast. Such a message may let the client join faster. But, then the server can send "request rejected" message as well. Yet, if it is an attack, we better drop it silently IMHO.

-acbegen

> From: Bill Ver Steeg (versteb)
> Sent: Wednesday, December 02, 2009 1:31 PM
> To: Ali C. Begen (abegen); Michael Lague (mlague); [email-masked]'
> Cc: Rob Drisko (rdrisko)
> Subject: RE: [AVT] the use of "media sender SSRC"indraft-ietf-avt-rapid-acquisition-for-
> rtp-05
> 
> We are in agreement, with the possible exception of "silently drop". I need to think about
> the relative merits of a RAMS-I with an error code of BAD_SSRC.
> 
> Bvs
> 
> 
> Subject: RE: [AVT] the use of "media sender SSRC"indraft-ietf-avt-rapid-acquisition-for-
> rtp-05
> 
> Some comments inline.
> 
> The unique feature about RAMS is that we send feedback before we see a source packet. In
> regular feedback (such as NACK), the receiver already knows the SSRC of the source stream.
> So, this is not a concern.
> 
> IMO, if the feedback target is solely serving for only one RTP stream, it should not care
> about the source SSRC in the received feedback messages.
> 
> Ow (meaning the feedback target is serving for more than one RTP streams), the requested
> SSRC must match to one of its streams. If it does not, FT silently drops the request.
> 
> I largely discussed this issue in the draft-begen-avt-rams-scenarios draft. We also
> discussed this in MMUSIC in the last meeting. The comments we received were all saying
> that strict SSRC management across potentially a large number of sources was not feasible
> (or even possible) without a well-defined protocol for it.
>

---

From: "Michael Lague (mlague)" <[email-masked]>
Date: Wed, 2 Dec 2009 14:23:26 -0600

A couple of comments inline.
--Mike Lague

> Subject: RE: [AVT] the use of "media sender SSRC"
> These are good points. I think these issues apply to the more general
RTCP feedback case, but we
> should be clear in our treatment of them in RAMS.
> 
system that does not use the
> same 3-tuple for a feedback target address for more than one stream,
the SSRC is indeed not required
> in the RAMS-R. For systems that do multiplex these feedback target
addresses, a unique SSRC is
> required to disambiguate the requests. If a unique SSRC is required,
the transition state from a given
> SSRC to another SSRC (for instance, in the case of a component
restart) may result in periods in which
> RTCP feedback requests will be ambiguous.

We're on exactly the same page. In fact, I think this is a better
description of the situation that the wording I used in my original
email.

> The main effect of an SSRC changing in mid-stream would be that RTCP
feedback (and thus RAMS) would
> not work until the RTP-Rx and the RS converge on a common SSRC.
> 
need to consider whether to have
> the RS silently ignore the RAMS-R request with an invalid SSRC or to
send a reject message to the
> originator.
> 
> Would it make sense to include a recommendation that systems that do
not have deterministic SSRCs use
> a single port per feedback target address? 

Yes, I think it would.

> This is really a RTP/RTCP concern, but I do not think this
> case is covered in detail elsewhere.
> 
> Bill VerSteeg
> 
Michael Lague (mlague)

---

From: Qin Wu <[email-masked]>
Date: Thu, 03 Dec 2009 15:36:44 +0800

Hi, Michael:
Some comments inline.
-Qin
----- Original Message ----- 
From: "Michael Lague (mlague)" <[email-masked]>
To: <[email-masked]>
Cc: "Rob Drisko (rdrisko)" <[email-masked]>
Sent: Thursday, December 03, 2009 12:00 AM
Subject: [AVT] the use of "media sender SSRC" indraft-ietf-avt-rapid-acquisition-for-rtp-05

>   transport address may be associated with more than one RTP stream, 

[Qin]: I think it is very common for one feedback target handle more than one RTP stream.
Even in the deployment scenario where we only have one media sender, one retransmission server, one
feedback target, two RTP Receivers one feedback target can handle two RTP stream for each RTP receiver at different time respectively.
am I right? 
one more question, where does the RTP stream associating with feedback target come from?
I guess RTP stream should be multicast RTP stream coming from media sender, right?

>    which the request was received.
[Qin]: 
Since feedback target transport address of the RS uniquely identifies a single RTP stream, 
both media sender SSRC of the RAMS-R and SSRC of the RTP steam IMO are redundant and not necessary,
The reason is RS does not need to care about SSRC of the RTP steam.
Also it is not clear how RS deal with the SSRC of the RTP stream? Inform this SSRC of the RTP stream to the RTP receiver?
 Is it the correct RTP stream which the RTP reciver are requesting?
In my opinion, maybe SSRC of RTP stream should be ignored as well.
Another reason to do this is I am difficult to understand why the feeback target transport address should be only
associated with one RTP stream? In my understanding, at different time, different RTP stream will be associated with the
Feedback target. How do know this RTP stream is what one RTP  receiver is requesting. If this stream is not what the RTP receiver is requesting,
it does not make sense for FT to push the RTP stream to the RTP reciever.
Would you like to clarify this?

 In such deployments the 'ssrc'

---

From: Qin Wu <[email-masked]>
Date: Thu, 03 Dec 2009 15:50:49 +0800

Hi, Ali and all:
See my comments linline.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Bill Ver Steeg (versteb)" <[email-masked]>; "Michael Lague (mlague)" <[email-masked]>; <[email-masked]>
Cc: "Rob Drisko (rdrisko)" <[email-masked]>
Sent: Thursday, December 03, 2009 1:23 AM
Subject: Re: [AVT] the use of "media sender SSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

> Ow (meaning the feedback target is serving for more than one RTP streams), the requested SSRC must match to one of its streams. If it does not, FT silently drops the request.

[Qin]: I share Ali's opinion on this.

> So, I believe we need to make that recommendation. Does anybody think otherwise?

[Qin]: I come to agree SSRC announcement is not necessary to RTP receiver if each feedback target transport address uniquely identify each RTP stream, We can simple just set media sender SSRC into value zero in the SDP for RTP receiver.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 3 Dec 2009 08:07:27 -0800

> [Qin]: I come to agree SSRC announcement is not necessary to RTP receiver if each feedback
> target transport address uniquely identify each RTP stream, We can simple just set media
> sender SSRC into value zero in the SDP for RTP receiver.

We cannot set anything in the SDP, that is the point in the discussion. If we set it, the receivers will think it is the correct SSRC. FYI, 0 could be a valid SSRC.

The open question is what we set the media sender SSRC in the feedback messages we sent if we don't know what it is. One idea is to set it to something but also add a field that says the media sender SSRC in that field is unknown and should be ignored by the server.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 3 Dec 2009 09:33:22 -0800

I'll take a shot at this.

[snip]
> [Qin]: I think it is very common for one feedback target handle more than one RTP stream.

I am not sure how common it is but one way or another this SSRC/FT association problem has to be handled.

> feedback target, two RTP Receivers one feedback target can handle two RTP stream for each
> RTP receiver at different time respectively.
> am I right?

When you say one feedback target, I am not sure whether you mean one physical FT or not. Let's use the term FTAp (feedback target address+port) for clarity. All I am saying is that each FTAp should serve only one RTP stream if there could be a possibility of ambiguity ow. 

> one more question, where does the RTP stream associating with feedback target come from?

Not sure what you ask here. If there is one RTP stream served per FTAp, the association is trivial.

> RTP stream to the RTP receiver?

Again not sure what you mean. It is the receiver that sends the first packet to the FTAp. If it does not know the media sender SSRC, then it does not know. 

>  Is it the correct RTP stream which the RTP reciver are requesting?

If the FTAp is serving one RTP stream only, then it should be the correct rTP stream. That's why we cannot serve two RTP streams on the same FTAp.

> associated with one RTP stream? In my understanding, at different time, different RTP

Sorry, you lost me. 

> stream will be associated with the
> Feedback target. How do know this RTP stream is what one RTP  receiver is requesting. If

If the RTP stream served by a specific FTAp changes over time, the receivers should be notified. As you can imagine, this brings up other problems to the front. Like what about the requests sent by the receivers before they received the updated information? Or what if they don't receive the new information ever?

I don't think this is a protocol issue. I think it is a deployment issue.

> this stream is not what the RTP receiver is requesting,

When we rely on the uniqueness of FTAp, we just need to make sure that the FTAp's don't change their responsibilities w/o making sure that every receiver is notified. Then, there won't be a problem.

In a world where we could also rely on the SSRCs, we could probably feel safer.

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 04 Dec 2009 20:33:32 +0800

Hi, Ali:
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Bill Ver Steeg (versteb)" <[email-masked]>; "Michael Lague (mlague)" <[email-masked]>; <[email-masked]>
Cc: "Rob Drisko (rdrisko)" <[email-masked]>
Sent: Friday, December 04, 2009 12:07 AM
Subject: RE: [AVT] the use of "media sender SSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

[Qin] It depends on how do you intepret value zero fo SSRC, it does not matter using value zero or value 0xFFFFFFFF or any other value to indicate client does not know media sender SSRC. 

-acbegen

---

From: Qin Wu <[email-masked]>
Date: Fri, 04 Dec 2009 20:36:15 +0800

Hi, Ali:
Please see my followup comments inline.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Michael Lague (mlague)" <[email-masked]>; <[email-masked]>
Cc: "Rob Drisko (rdrisko)" <[email-masked]>
Sent: Friday, December 04, 2009 1:33 AM
Subject: RE: [AVT] the use of "media sender SSRC" indraft-ietf-avt-rapid-acquisition-for-rtp-05

[snip]

[Qin]: Okay,I agree.

[Qin]: I am wondering whether one FT can be shared by multiple receiver at the same time. It seems to me FT is not used to deliver RTP stream to the 
receiver? It is burst source's responsibility to deliver each RTP stream to each receiver? But you are right, FT can use different port to distinguish different RAMS-R from receivers. That is to say, it is true FT can be shared by multiple receiver at the same time. But FTAP should be dedicating to serve only one receiver at each time.Am I right?

[Qin]: Isn't it one association between one RTP stream and one FTAp?

[Qin]: But it is still one assocication between one RTP stream and one FTAp.

[Qin]: What I am saying is since RS ignore SSRC of media sender, RS should ignore using SSRC of the corresponding RTP stream as well. 
Because in such deployment scenario, SSRC is not important and necessary any more.

[Qin]: Okay. 
One more question is how do you look at the relationship between FTAp and Burst Source? one to one?

Sorry, you lost me. 

[Qin]:Since each FTAp only serve one RTP stream, one receiver, that is to say, FTAp can not serve another reciever at the same time, I tend to agree with your
opinion.

[Qin]Okay.

[Qin]: It seems to me each FTAp offers a dedicated path to each receiver for each RTP stream.

-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Dec 2009 13:13:06 +0000

On 4 Dec 2009, at 12:33, Qin Wu wrote:

> To: "Qin Wu" <[email-masked]>; "Bill Ver Steeg (versteb)" <[email-masked] 
> >; "Michael Lague (mlague)" <[email-masked]>; <[email-masked]>
> We cannot set anything in the SDP, that is the point in the  
> discussion. If we set it, the receivers will think it is the correct  
> SSRC. FYI, 0 could be a valid SSRC.
>
> The open question is what we set the media sender SSRC in the  
> feedback messages we sent if we don't know what it is. One idea is  
> to set it to something but also add a field that says the media  
> sender SSRC in that field is unknown and should be ignored by the  
> server.
>
> [Qin] It depends on how do you intepret value zero fo SSRC, it does  
> not matter using value zero or value 0xFFFFFFFF or any other value  
> to indicate client does not know media sender SSRC.

All values in the range 0x00000000 - 0xffffffff are legal SSRC values.  
You cannot use them to signal that the client does not know the media  
sender's SSRC.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 4 Dec 2009 06:43:05 -0800

> You cannot use them to signal that the client does not know the media

Indeed. IMO, if the SDP does not specify the media sender SSRC for a specific multicast stream, then the feedback target responsible for that RTP stream should not be validating the media sender SSRC field of the incoming feedback messages. In addition, we can still add a field to the feedback report to make this explicit. If anybody has a better alternative, please speak up.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 4 Dec 2009 06:53:33 -0800

> When you say one feedback target, I am not sure whether you mean one physical FT or not.
> Let's use the term FTAp (feedback target address+port) for clarity. All I am saying is
> that each FTAp should serve only one RTP stream if there could be a possibility of
> ambiguity ow.
> 
> [Qin]: I am wondering whether one FT can be shared by multiple receiver at the same time.
> It seems to me FT is not used to deliver RTP stream to the
> receiver? It is burst source's responsibility to deliver each RTP stream to each receiver?

Of course, FT is common to all receivers receiving a particular RTP stream. It is not per receiver. 

In the RAMS architecture, for many good reasons, we collectively call the entity that functions as FT, retransmission source and burst source as Retransmission Server.

> But you are right, FT can use different port to distinguish different RAMS-R from
> receivers. That is to say, it is true FT can be shared by multiple receiver at the same
> time. But FTAP should be dedicating to serve only one receiver at each time.Am I right?

See above. FTAp should be per stream if there is no unique SSRC signaling. In either case, it is not per receiver.
 
[snip]
> Again not sure what you mean. It is the receiver that sends the first packet to the FTAp.
> If it does not know the media sender SSRC, then it does not know.
> 
> [Qin]: What I am saying is since RS ignore SSRC of media sender, RS should ignore using
> SSRC of the corresponding RTP stream as well.

Huh? SSRC is important. The retransmission/burst packets must have their SSRC's set right. In RAMS, we are doing session multiplexing between the multicast stream and unicast burst/ret stream. See RFC 4588 for details.

> If the FTAp is serving one RTP stream only, then it should be the correct rTP stream.
> That's why we cannot serve two RTP streams on the same FTAp.
> 
> [Qin]: Okay.

Let me put it this way. In a retransmission server, there may be several FTAps (on different ports, for example) and multiple burst sources tied to each FTAp. But, as you will recall Burst Source is a virtual entity in the retransmission server.
 
-acbegen

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 7 Dec 2009 12:45:32 +0100

Hi,

My view is that out-of-band SSRC signaling should be recommended in the
context of RAMS. However, in order to deal for example with the failure
cases when SSRC's change in the SSM RTP streams generated by media
senders, a RS should be "prepared" to deal with incorrect media sender
SSRC values in the RAMS-Request messages. Therefore , from the RR point
of view, the RS response on a RAMS-R with "incorrect" media sender SSRC
value, could be

1)an RTP burst with the proper  media sender SSRC. Following RFC 4588,
this "proper" media sender SSRC is then transmitted by the RS in the
retransmission packet RTP header. This means that the RAMS-R was
successfuly responded upon by the RS. The RS may only act in such a way
if there is a 1-to-1 mapping between FT transport address and associated
SSM RTP stream (..which is known to the RS, not to the RTP receiver).
This means that in this case the RS may even ignore in its normal
operational mode the  value of the "media sender SSRC" field in the
RAMS-R messages, as there is never any ambiguity. This is an
implementation choice.  

2)no RTP burst, but a RAMS-I message which indicates unsuccesful
response. 
The RAMS draft now has a defined a response code 400 with meaning
"Invalid RAMS-R message syntax". It may be worthwile to consider a new
dedicated response code 404 with meaning "Invalid media sender SSRC in
RAMS-R". The RS must respond in this way when there is NOT a 1-to-1
mapping between FT transport address and SSM RTP streams, each having a
SSRC value which is different from the one received in the RAMS-R
message. This may also be the behaviour of a RS which does always
inspect the media sender SSRC value in the RTCP FB messages, and only
services the RTCP message (NACK or RAMS-R) when the SSRC is correct,
irrespective whether there are disambiguities or not.  Note, that in the
case when there is NO 1-to-1 mapping between FT and SSM, there is an
additional issue when the RS sends the RAMS-I RTCP message with error
code. The RS sends the RAMS-I message in the retransmission session and
following RFC 4588, the media sender SSRC in the retransmission session
packets  must be the one used in the associated primary (original) SSM.
However, if there are at least two  SSRC values/SSMs possible, which
SSRC value must be used then in the "SSRC of packet sender" field and in
the "SSRC of media sender" field of the RAMS-I message? 
This also means that the RTP receiver cannot assume that the SSRC value
inside the RTCP RAMS-I RTCP message header is the "proper" SSRC of the
SSM requested with the RAMS-R. It may be interesting to consider
defining a new optional TLV element for signaling in the RAMS-I the
"proper" SSRC value, which is hence an in-band delivery option for the
SSRC.   This in-band SSRC delivery provides a solution for the cases
described earlier in this email thread where a media sender changes SSRC
(restart or redundant switch-over). The RS will  be the one noticing the
SSRC change in the SSM RTP stream, and when there is an incoming RAMS-R
for the "old" SSRC, the "new" SSRC can be signaled with the new TLV
element embedded in the RAMS-I message.  Note however that this should
not be the default mechanism of signaling SSRC values in the context of
RAMS .. that is why "out-of-band" SSRC signaling must at least be
"recommended" for RAMS.

In the case 2, when the RTP receiver does not receive an RTP burst but
only a RAMS-I with error response code 400 (or 404), the RTP receiver
must NOT make any RAMS-R requests anymore to this FT when it does not
know the right "SSRC" IMO. Only when the RTP receiver receives this new
TLV containing the proper SSRC, or when resolving the right SSRC in a
different way (out-of-band, or by receiving directly the SSM RTP flow
without RAMS), it MAY do so, by using this new SSRC value. 

What do you think?

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: vrijdag 4 december 2009 15:43
To: Colin Perkins; Qin Wu
Cc: Rob Drisko (rdrisko); [email-masked]; Bill Ver Steeg (versteb)
Subject: Re: [AVT] the use of "mediasender
SSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

> You cannot use them to signal that the client does not know the media 

Indeed. IMO, if the SDP does not specify the media sender SSRC for a
specific multicast stream, then the feedback target responsible for that
RTP stream should not be validating the media sender SSRC field of the
incoming feedback messages. In addition, we can still add a field to the
feedback report to make this explicit. If anybody has a better
alternative, please speak up.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 7 Dec 2009 07:39:08 -0800

Hi Tom,

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Monday, December 07, 2009 6:46 AM
> To: Ali C. Begen (abegen); Colin Perkins; Qin Wu
> Subject: RE: [AVT] the use of "mediasender SSRC"indraft-ietf-avt-rapid-acquisition-for-
> rtp-05
> 
> Hi,
> 

In scenarios where there is 1:1 mapping in FTAp's and source streams, I believe the draft should define what RS has to do, which should be IMO that it sends the media stream with the correct SSRC (as you said above) ignoring the SSRC specified in the RAMS-R message. We should not leave this behavior up to implementation. 

Furthermore, the draft should also specify what RS should do when there is no 1:1 mapping. 
 
> SSRC value which is different from the one received in the RAMS-R

So, you think RS should let the receiver know about this?

> inside the RTCP RAMS-I RTCP message header is the "proper" SSRC of the

Right, it cannot. So, this RAMS-I message only serves the purpose of letting the receiver know that its SSRC request did not match to any of the served SSRCs by this FTAp.

> SSRC change in the SSM RTP stream, and when there is an incoming RAMS-R

Actually, all receivers that already subscribed to those specific SSM sessions will also see the SSRC changes. But, other receivers will be clueless until they are somehow told.

In deployments with 1:1 mapping, this is not an issue. In other deployments, updated SDPs with the new SSRC information must be distributed as soon as possible to minimize the errors.

> element embedded in the RAMS-I message.  Note however that this should

Is it likely for the receiver to try another RAMS attempt with the new SSRC after receiving the correct SSRC? Maybe, it is. But, for the server to tell the receiver the correct SSRC, it must remember which SSRC has replaced which SSRC. And this info must be accurate.

What about the following case?

(An FTAp serving for two source streams)
Time=0:
Source 1: SSRC1, Source 2: SSRC2

Time=100:
Source 1: SSRC2, Source 2: SSRC3

When a RAMS-R arrives asking for SSRC2, what does RS do? The receiver could be asking for source 1 or source 2. How do we know?	

Or, at time=200, it could be:
Source 1: SSRC4, Source 2: SSRC5

Now, a request for SSRC2 arrives. We are stuck again. 

IMO, we should not require the retransmission server to remember all these possibilities and keep additional state.

> RAMS .. that is why "out-of-band" SSRC signaling must at least be

We need to be careful about the wording here. The requirement for the out-of-band signaling is currently a "must" regardless of whether FTAp's serve for a single or multiple source streams. This must be revised.

IMO, we must separate the requirements and list them separately for each of the two possible scenarios (according to whether a 1:1 mapping exists or not). The former case is simple. For the latter case, there may exist a lot of nasty scenarios that the FTAp's may need to deal with. I suggest that the draft merely mentions the problems and requires the implementations to deal with them (rather than imposing specific solutions).
 
> know the right "SSRC" IMO. Only when the RTP receiver receives this new

Agree.

> without RAMS), it MAY do so, by using this new SSRC value.

See above.

-acbegen

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 11 Dec 2009 11:48:22 +0100

Hi Ali,

I can agree with your views:
-if there is a one-to-one mapping between FT port address and RTP stream
(with a specific SSRC), there is NO requirement on signaling the SSRC
values to the RTP receivers and the RS must ignore in the RAMS-R
messages the media sender SSRC value.
-if there is no one-to-one mapping, the SSRC values must be signaled to
the RTP receivers prior to RAMS-interactions and the RS must not ignore
the media sender SSRC values in the RAMS-R messages. 

In this second latter case, when the RS receives a RAMS-R with "invalid"
media sender SSRC, it must respond with a RAMS-I error message (and no
RTP burst). We should also have text then that the "media sender SSRC"
and "packet sender SSRC" in this RAMS-I message should be ignored by the
RTP receiver for the reasoning I gave in my previous email. I think it
would be interesting to add "invalid SSRC" as error message. You are
right that a RS cannot resolve with 100% certitude in all corner cases
which is the RTP stream (identified by SSRC) the RTP receiver wants to
receive by means of RAMS, so a new TLV for in-band SSRC signaling is not
a solid solution in this case.

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: maandag 7 december 2009 16:39
To: VAN CAENEGEM Tom; Colin Perkins; Qin Wu
Cc: Rob Drisko (rdrisko); [email-masked]; Bill Ver Steeg (versteb)
Subject: Re: [AVT] the use of
"mediasenderSSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

Hi Tom,

> Subject: RE: [AVT] the use of "mediasender 
> My view is that out-of-band SSRC signaling should be recommended in 
> the context of RAMS. However, in order to deal for example with the 
> failure cases when SSRC's change in the SSM RTP streams generated by 
> media senders, a RS should be "prepared" to deal with incorrect media 
> sender SSRC values in the RAMS-Request messages. Therefore , from the 
> RR point of view, the RS response on a RAMS-R with "incorrect" media 
> sender SSRC value, could be
> 

> successfuly responded upon by the RS. The RS may only act in such a 
> way if there is a 1-to-1 mapping between FT transport address and 
> associated SSM RTP stream (..which is known to the RS, not to the RTP
receiver).
> RAMS-R messages, as there is never any ambiguity. This is an 

In scenarios where there is 1:1 mapping in FTAp's and source streams, I
believe the draft should define what RS has to do, which should be IMO
that it sends the media stream with the correct SSRC (as you said above)
ignoring the SSRC specified in the RAMS-R message. We should not leave
this behavior up to implementation. 

Furthermore, the draft should also specify what RS should do when there
is no 1:1 mapping. 

> mapping between FT transport address and SSM RTP streams, each having 
> a SSRC value which is different from the one received in the RAMS-R

> irrespective whether there are disambiguities or not.  Note, that in 
> the case when there is NO 1-to-1 mapping between FT and SSM, there is 
> an additional issue when the RS sends the RAMS-I RTCP message with 
> error code. The RS sends the RAMS-I message in the retransmission 
> session and following RFC 4588, the media sender SSRC in the 
> retransmission session packets  must be the one used in the associated
primary (original) SSM.
> SSRC value must be used then in the "SSRC of packet sender" field and 
> in the "SSRC of media sender" field of the RAMS-I message?
> This also means that the RTP receiver cannot assume that the SSRC 
> value inside the RTCP RAMS-I RTCP message header is the "proper" SSRC 
> of the

Right, it cannot. So, this RAMS-I message only serves the purpose of
letting the receiver know that its SSRC request did not match to any of
the served SSRCs by this FTAp.

> described earlier in this email thread where a media sender changes 
> SSRC (restart or redundant switch-over). The RS will  be the one 
> noticing the SSRC change in the SSM RTP stream, and when there is an 
> incoming RAMS-R

Actually, all receivers that already subscribed to those specific SSM
sessions will also see the SSRC changes. But, other receivers will be
clueless until they are somehow told.

In deployments with 1:1 mapping, this is not an issue. In other
deployments, updated SDPs with the new SSRC information must be
distributed as soon as possible to minimize the errors.

> element embedded in the RAMS-I message.  Note however that this should

Is it likely for the receiver to try another RAMS attempt with the new
SSRC after receiving the correct SSRC? Maybe, it is. But, for the server
to tell the receiver the correct SSRC, it must remember which SSRC has
replaced which SSRC. And this info must be accurate.

Time=100:

When a RAMS-R arrives asking for SSRC2, what does RS do? The receiver
could be asking for source 1 or source 2. How do we know?	

IMO, we should not require the retransmission server to remember all
these possibilities and keep additional state.

> not be the default mechanism of signaling SSRC values in the context 
> of RAMS .. that is why "out-of-band" SSRC signaling must at least be 
> "recommended" for RAMS.

We need to be careful about the wording here. The requirement for the
out-of-band signaling is currently a "must" regardless of whether FTAp's
serve for a single or multiple source streams. This must be revised.

IMO, we must separate the requirements and list them separately for each
of the two possible scenarios (according to whether a 1:1 mapping exists
or not). The former case is simple. For the latter case, there may exist
a lot of nasty scenarios that the FTAp's may need to deal with. I
suggest that the draft merely mentions the problems and requires the
implementations to deal with them (rather than imposing specific
solutions).

Agree.

See above.

-acbegen

> > > [Qin] It depends on how do you intepret value zero fo SSRC, it 
> > > does not matter using value zero or value 0xFFFFFFFF or any other 
> > > value to indicate client does not know media sender SSRC.
> >
> >
> > You cannot use them to signal that the client does not know the 
> > media sender's SSRC.
> 
> specific multicast stream, then the feedback target responsible for 
> that RTP stream should not be validating the media sender SSRC field 
> of the incoming feedback messages. In addition, we can still add a 
> field to the feedback report to make this explicit. If anybody has a 
> better alternative, please speak up.
> 
> -acbegen
> 
> 
> > --
> > Colin Perkins
> > http://csperkins.org/
> >
> >
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 11 Dec 2009 08:41:32 -0600

Tom, Ali-

There is broad agreement on the core points of this issue.

The remaining point is whether the RS silently ignores RAMS-R with an
invalid SSRC on a multiplexed port or if it returns an error message. We
should consider the case in which this is a mis-configuration (in which
an error message is probably appropriate) or the case in which this is
some sort of malicious act (in which a silent drop is probably
appropriate). 

Perhaps a scheme in which an error message is sent for some number (some
percentage? Some threshold?) of such messages, but they are silently
ignored after that. This addresses the most obvious DOS concerns. Are
there other security concerns we should be considering?

It is difficult to capture all of the security concerns. If we agree
that there is some leeway in implementation on this point, the wording
would be something along the lines of "When receiving a RAMS-R with an
invalid SSRC on a port that is configured to handle more than one SSRC,
the RS MAY send an error message of format xxx, or it may silently
ignore such messages. The RS should make this decision based on loading
factors, the frequency of such events, and the overall security profile
of the system." 

Bvs

-----Original Message-----
From: VAN CAENEGEM Tom [mailto:[email-masked]] 
Sent: Friday, December 11, 2009 5:48 AM
To: Ali C. Begen (abegen); Colin Perkins; Qin Wu
Cc: Rob Drisko (rdrisko); [email-masked]; Bill Ver Steeg (versteb)
Subject: RE: [AVT] the use of

Hi Ali,

Tom

-----Original Message-----

Hi Tom,

receiver).

 

primary (original) SSM.

Time=100:

 

Agree.

See above.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 09:54:30 +0200

Hi,
I think that the issue of changing SSRC is discussed in the beginning of
section 4 of RFC 4588 (retransmission)
Roni

> Bill Ver Steeg (versteb)
> Sent: Wednesday, December 02, 2009 6:18 PM
> Subject: Re: [AVT] the use of "media sender SSRC" indraft-ietf-avt-
> rapid-acquisition-for-rtp-05
> 
> Michael-
> 
> not

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 14:58:17 +0200

Hi Bill,
I assume that if there is a component restart (multicast source) it will be
followed by a session announcement since other values may change and so the
RS and RTP_Rx will get the new values. Anyhow in this case the RS will need
to accumulate some data from the multicast stream in order to be able to
provide the information needed for RAMS. 

I also noted the case the existing multicast systems may not be able to
provide the SSRC but in this case they will not be able to provide the SDP
needed for RAMS support and if you change their code you may add the SSRC
provision support.

So I am not sure that the solution is broken. Yet I see no harm in adding
the text about using a different transport for each stream but it should be
optional.

Roni

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 16:00:13 +0200

Hi,
I think that we need to look at it from the start. My understanding is that
the SSRC was changed by the multicast source and not by the RS. This is in
the primary multicast session and will need to change by doing an RTCP BYE
before the change to the new value. In this case the multicast source will
probably need to send a new SDP. 
The RS will receive the change in the primary multicast channel which he
follows and will need to terminate the current unicast bursts and also note
the new stream information. If the multicast source sends a new SDP than all
will know the new SSRC

Roni Even
As individual (Please look at all my comments on RAMS as individual comments
even if I forget to mention, I will write "as AVT chair" when I will respond
under the chairs's hat)

> VAN CAENEGEM Tom
> Sent: Monday, December 07, 2009 1:46 PM
> Subject: Re: [AVT] the use of "mediasender SSRC"indraft-ietf-avt-rapid-
> acquisition-for-rtp-05
> 
> Hi,
> 
> in
> SSRC
> that

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Dec 2009 06:59:25 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Wednesday, December 16, 2009 7:58 AM
> Subject: Re: [AVT] the use of "media senderSSRC" indraft-ietf-avt-rapid-acquisition-for-
> rtp-05
> 
> Hi Bill,

Not every component restart will necessarily generate a new SDP. There can be multiple sources in a system for redundancy or scale purposes but the SDP may remain the same. This is not a concern even if the restarted component uses a different SSRC as long as the SSRC's are not announced in the SDP description.

> provide the information needed for RAMS.

Right, RS will be listening to the multicast sessions anyway. If there is an SSRC change, it will see it anyway. But the receivers cannot. That's why we need to change the current text.
 
> needed for RAMS support and if you change their code you may add the SSRC

Strict SSRC management requires more than this. It requires the sources to coordinate the SSRCs for all streams. We currently don't have a protocol for this and to my understanding nobody thinks we need to produce a new one. In systems where this can be done, yeah sure, they can announce the SSRCs in the SDP descriptions. For others, we will remove that requirement but they will have to serve a single RTP stream on any given FT address+port.
 
-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 17:02:10 +0200

Hi,
The problem with this approach is that if RAMS is based on RFC4588 than the
RTP_Rx will expect to get a retransmission with the SSRC he requested so you
lose compliance to RFC4588 which was an assumption in RAMS. 

One other question is that I think that sending a different SSRC from the
requested one will cause a problem on the receiver in the case where he
receives sent two different RAMS-R requests and get two streams with new
SSRCs, see section 5.3 of RFC 4588 

I can think of another solution by which the RS will send the original
payload (e.g. MP2T) and not a retransmission stream.

Roni Even

> Sent: Friday, December 11, 2009 4:42 PM
> To: VAN CAENEGEM Tom; Ali C. Begen (abegen); Colin Perkins; Qin Wu
> Cc: Rob Drisko (rdrisko); [email-masked]
> Subject: Re: [AVT] the use of "mediasenderSSRC"indraft-ietf-avt-rapid-
> acquisition-for-rtp-05
> 
> Tom, Ali-
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Dec 2009 07:16:57 -0800

> From: Roni Even [mailto:[email-masked]]
> Sent: Wednesday, December 16, 2009 9:00 AM
> To: 'VAN CAENEGEM Tom'; Ali C. Begen (abegen); 'Colin Perkins'; 'Qin Wu'

Right, RS can learn the new SSRCs from the RTP packets as it is already listening to the multicast sessions.

> before the change to the new value. In this case the multicast source will

If the source fails, it won't be sending a BYE. In redundancy schemes, an alternative source will take its place right away. But, the problem is we cannot guarantee that it will use the same SSRC. That's why the rules in 4588 don't help us much.

> probably need to send a new SDP.

To be able to announce the SSRCs in the SDP, the same SSRCs need to be used by all the sources for the same stream. If we cannot do that, we better not announce the SSRCs.

> the new stream information. If the multicast source sends a new SDP than all

If the SSRC changes during the RAMS, RAMS will probably be useless (and fail) anyway. As soon as an RTP receiver (be it RS or the actual RTP receiver in the RAMS scenario) sees a change in the SSRC, it will clear some of the stats, etc.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 17:23:06 +0200

Ali,
About,
Strict SSRC management requires more than this. It requires the sources to
coordinate the SSRCs for all streams. We currently don't have a protocol for
this and to my understanding nobody thinks we need to produce a new one

I think that RFC 4588 section 4 first paragraph discuss this. So if the
source discovers a collision in one of the streams it must send a bye in all
streams and restart with new SSRC.
Roni

> Sent: Wednesday, December 16, 2009 4:59 PM
> To: Roni Even; Bill Ver Steeg (versteb); Michael Lague (mlague);
> [email-masked]
> Cc: Rob Drisko (rdrisko)
> Subject: Re: [AVT] the use of "media senderSSRC" indraft-ietf-avt-
> Not every component restart will necessarily generate a new SDP. There
> can be multiple sources in a system for redundancy or scale purposes
> but the SDP may remain the same. This is not a concern even if the
> restarted component uses a different SSRC as long as the SSRC's are not
> announced in the SDP description.
> 
> Right, RS will be listening to the multicast sessions anyway. If there
> is an SSRC change, it will see it anyway. But the receivers cannot.
> That's why we need to change the current text.
> 
> Strict SSRC management requires more than this. It requires the sources
> to coordinate the SSRCs for all streams. We currently don't have a
> protocol for this and to my understanding nobody thinks we need to
> produce a new one. In systems where this can be done, yeah sure, they
> can announce the SSRCs in the SDP descriptions. For others, we will
> remove that requirement but they will have to serve a single RTP stream
> on any given FT address+port.
> 
> -acbegen
>

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 16 Dec 2009 17:03:28 +0100

Roni,

If an RTP receiver transmits a NACK, it will always use the right media
sender SSRC in this NACK, because it already receives the SSM with (the
right) media sender SSRC inside the RTP packet headers. 

If an RTP receiver transmits a RAMS-R with a "wrong" media sender SSRC
(this is the case where there is a 1-to-1 mapping between SSRC and RS/FT
transport address, and SSRCs of the RTP stream(s) in the SSM are not
signaled), the response is -in general- a burst of retransmission
packets which have a media sender SSRC that is different from the one
that is requested. But even if there are multiple RAMS-R requests
transmitted by the same RTP receiver, the response bursts will be
segregated based on the different media sender SSRCs. The difference
with RFC 4588, is that the RTP receiver receives first the
retransmission packets and then the original packets (in the SSM), and
the association between these RTP streams/packets (which original packet
stream matches with which received burst of retransmission packets) can
still be done as described in RFC4588, no? Where do you see loss of
compliance with RFC4588?

Tom

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: woensdag 16 december 2009 16:02
To: 'Bill Ver Steeg (versteb)'; VAN CAENEGEM Tom; 'Ali C. Begen
(abegen)'; 'Colin Perkins'; 'Qin Wu'
Cc: 'Rob Drisko (rdrisko)'; [email-masked]
Subject: RE: [AVT] the use
of"mediasenderSSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

Hi,
The problem with this approach is that if RAMS is based on RFC4588 than
the RTP_Rx will expect to get a retransmission with the SSRC he
requested so you lose compliance to RFC4588 which was an assumption in
RAMS. 

One other question is that I think that sending a different SSRC from
the requested one will cause a problem on the receiver in the case where
he receives sent two different RAMS-R requests and get two streams with
new SSRCs, see section 5.3 of RFC 4588 

Roni Even

> should consider the case in which this is a mis-configuration (in 
> which an error message is probably appropriate) or the case in which 
> this is some sort of malicious act (in which a silent drop is probably

> appropriate).
> 
> Perhaps a scheme in which an error message is sent for some number 
> (some percentage? Some threshold?) of such messages, but they are 
> silently ignored after that. This addresses the most obvious DOS 
> concerns. Are there other security concerns we should be considering?
> 

> invalid SSRC on a port that is configured to handle more than one 
> SSRC, the RS MAY send an error message of format xxx, or it may 
> silently ignore such messages. The RS should make this decision based 
> on loading factors, the frequency of such events, and the overall 
> security profile of the system."
> 
> Bvs
> 
> 
> -if there is a one-to-one mapping between FT port address and RTP 
> stream (with a specific SSRC), there is NO requirement on signaling 
> the SSRC values to the RTP receivers and the RS must ignore in the 
> RAMS-R messages the media sender SSRC value.
> -if there is no one-to-one mapping, the SSRC values must be signaled 
> to the RTP receivers prior to RAMS-interactions and the RS must not 
> ignore the media sender SSRC values in the RAMS-R messages.
> 

> and "packet sender SSRC" in this RAMS-I message should be ignored by 
> the RTP receiver for the reasoning I gave in my previous email. I 
> think it would be interesting to add "invalid SSRC" as error message. 
> You are right that a RS cannot resolve with 100% certitude in all 
> corner cases which is the RTP stream (identified by SSRC) the RTP 
> receiver wants to receive by means of RAMS, so a new TLV for in-band 
> SSRC signaling is not a solid solution in this case.
> 
> Tom
> 
> 
> 
> 

> > media senders, a RS should be "prepared" to deal with incorrect 
> > media sender SSRC values in the RAMS-Request messages. Therefore , 
> > from the RR point of view, the RS response on a RAMS-R with 
> > "incorrect" media sender SSRC value, could be
> >

> In scenarios where there is 1:1 mapping in FTAp's and source streams, 
> I believe the draft should define what RS has to do, which should be 
> IMO that it sends the media stream with the correct SSRC (as you said
> above)

> > mapping between FT transport address and SSM RTP streams, each 
> > having a SSRC value which is different from the one received in the 
> > RAMS-R
> 
> > inspect the media sender SSRC value in the RTCP FB messages, and 
> > only services the RTCP message (NACK or RAMS-R) when the SSRC is 
> > correct, irrespective whether there are disambiguities or not.  
> > Note, that in the case when there is NO 1-to-1 mapping between FT 
> > and SSM, there is an additional issue when the RS sends the RAMS-I 
> > RTCP message with error code. The RS sends the RAMS-I message in the

> > retransmission session and following RFC 4588, the media sender SSRC

> > in the retransmission session packets  must be the one used in the
> associated
> primary (original) SSM.

> > SSRC value must be used then in the "SSRC of packet sender" field 
> > and in the "SSRC of media sender" field of the RAMS-I message?
> > value inside the RTCP RAMS-I RTCP message header is the "proper" 
> > SSRC of the
> 
> letting the receiver know that its SSRC request did not match to any 
> of the served SSRCs by this FTAp.
> 

> SSRC after receiving the correct SSRC? Maybe, it is. But, for the 
> server to tell the receiver the correct SSRC, it must remember which 
> SSRC has replaced which SSRC. And this info must be accurate.
> 

> out-of-band signaling is currently a "must" regardless of whether 
> FTAp's serve for a single or multiple source streams. This must be 
> revised.
> 
> IMO, we must separate the requirements and list them separately for 
> each of the two possible scenarios (according to whether a 1:1 mapping

> exists or not). The former case is simple. For the latter case, there 
> may exist a lot of nasty scenarios that the FTAp's may need to deal 
> with. I suggest that the draft merely mentions the problems and 
> requires the implementations to deal with them (rather than imposing 
> specific solutions).
> 
> > only a RAMS-I with error response code 400 (or 404), the RTP 
> > receiver must NOT make any RAMS-R requests anymore to this FT when 
> > it does not know the right "SSRC" IMO. Only when the RTP receiver 
> > receives this new
> 
> Agree.
> 
> > TLV containing the proper SSRC, or when resolving the right SSRC in 
> > a different way (out-of-band, or by receiving directly the SSM RTP 
> > flow without RAMS), it MAY do so, by using this new SSRC value.
> 
> See above.
> 
> -acbegen
> 
> >
> > What do you think?
> >
> > Tom
> >
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Ali C. Begen (abegen)
> > > > sender SSRC in that field is unknown and should be ignored by 
> > > > the server.
> > > >
> > > > does not matter using value zero or value 0xFFFFFFFF or any 
> > > > other value to indicate client does not know media sender SSRC.
> > >
> > >

---

From: Roni Even <[email-masked]>
Date: Wed, 16 Dec 2009 18:46:06 +0200

Hi,
>From the receivers point of view there is no association between the
original stream (this is the SSRC he sent) and the retransmission stream.
This is not in line with the association rules of RFC 4588 for session
multiplexing (section 5.3)
Roni Even as Individual

> Sent: Wednesday, December 16, 2009 6:03 PM
> To: Roni Even; Bill Ver Steeg (versteb); Ali C. Begen (abegen); Colin
> Perkins; Qin Wu
> Subject: RE: [AVT] the use of"mediasenderSSRC"indraft-ietf-avt-rapid-
> acquisition-for-rtp-05
> 
> Roni,
>