Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 16 Apr 2009 12:38:56 -0400

There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions
(RAMS)" draft available at
http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniza
tion-for-rtp-03.txt
<http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchroniz
ation-for-rtp-03.txt> 
 
We have incorporated the changes from the technical breakout session in
San Francisco. The major changes in this version of the draft include 
1- Changing the document title to avoid confusion with other ongoing
"synchronization" drafts
2- changing the message names to reflect the title change
3- clarification of the RTCP message semantics, including changes to the
"Request" and "Inform" messages
4- additional description/motivation for the various message flows has
been added
5- RTP/RTCP muxing has been added

We hope to make this a Working Group item, and will change the name of
the draft to avoid conflicts with other "synchronization" drafts at that
time.
 
Bill VerSteeg

---

From: Zou ZiXuan <[email-masked]>
Date: Fri, 24 Apr 2009 18:02:54 +0800

Hi,

         The burst duration (8 octets) in RAMS-I message is in a single
RTP ticks. And I note that from draft-01 on, the solution is
payload-independent (is my understanding correct?). So, for non-MEPG2-TS
payload, for example, H.264-NAL where audio and video content are
encapsulated separately in two RTP streams with different ticks, does
the duration indicated by this single ticks still work? Which stream
does this tick belong to?

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bill Ver Steeg (versteb)
Sent: Friday, April 17, 2009 12:39 AM
To: [email-masked]
Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions
(RAMS)" available

 

Bill VerSteeg

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 14:24:16 +0300

Hi,

I think that the current draft does not give a description of a system that
works since there is no text explaining how the RS knows the unicast
transport address on the RR to where to send the stream. 

If you mandate the use of RTP/RTCP mux it should say so otherwise the RAMS-R
should have an optional parameter that supplies this information and a flag
for using RTP/RTCP mux.

Thanks

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Ver Steeg (versteb)
Sent: Thursday, April 16, 2009 7:39 PM
To: [email-masked]
Subject: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions
(RAMS)" available

There is a new draft of the "Rapid Acquisition of Multicast RTP Sessions
(RAMS)" draft available at
<http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchronizatio
n-for-rtp-03.txt>
http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-synchronization
-for-rtp-03.txt

We have incorporated the changes from the technical breakout session in San
Francisco. The major changes in this version of the draft include 

4- additional description/motivation for the various message flows has been
added

 

We hope to make this a Working Group item, and will change the name of the
draft to avoid conflicts with other "synchronization" drafts at that time.

Bill VerSteeg

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 08:12:46 -0700

Hi Zou,

This is a very good question. Let me take a stab here.

Per RFC 3550, each SSRC space has its own clock rate and seq numbering. We include the SSRC in the RAMS request messages.

There are different flavors of your scneario. Lets assume that we have two RTP streams (audio and video).

Case 1: Different RTP sessions are transmitted over different mcast groups.

Here, we run a different independent RAMS session for each RTP stream that we want to rapidly acquire (they can run in parallel). Here one needs to pay attention to how to use the shared bandwidth among different bursts, though.

Case 2: Different RTP sessions are transmitted over the same mcast group (with different dest ports).

Again, we run a different independent RAMS for each RTP stream (different request for each, etc). But, one should keep in mind that the join times for the all RAMS sessions need to be common as there is only one multicast.

Case 3: One RTP session (same mcast group, same dest port) carrying both audio and video (this is SSRC multiplexing).

Similar to case 2, join time needs to be coordinated among different RAMS sessions running for each RTP stream. Since we signal SSRC in the request message and we have independent RAMS sessions, using different clock rates is not an issue.

Case 4: One RTP session, one SSRC with payload type multiplexing. This is not recommended for many reasons. On top of that, different payloads with different clock rates cannot be multiplexed in this fashion. So, I don't think this will apply to our problem.

HTH,
-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Zou ZiXuan
> Sent: Friday, April 24, 2009 3:03 AM
> To: Bill Ver Steeg (versteb); [email-masked]
> Subject: Re: [AVT] New draft of "Rapid Acquisition of 
> Multicast RTP Sessions (RAMS)" available
> 
> Hi,
> 
>          The burst duration (8 octets) in RAMS-I message is 
> in a single RTP ticks. And I note that from draft-01 on, the 
> solution is payload-independent (is my understanding 
> correct?). So, for non-MEPG2-TS payload, for example, 
> H.264-NAL where audio and video content are encapsulated 
> separately in two RTP streams with different ticks, does the 
> duration indicated by this single ticks still work? Which 
> stream does this tick belong to?
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bill Ver Steeg (versteb)
> Subject: [AVT] New draft of "Rapid Acquisition of Multicast 
> RTP Sessions (RAMS)" available
> 
>  
> 
> There is a new draft of the "Rapid Acquisition of Multicast 
> RTP Sessions (RAMS)" draft available at 
> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s
ynchronization-for-rtp-03.txt <http://www.ietf.org/internet-> drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt> 
> 
>  
> 
> We have incorporated the changes from the technical breakout 
> session in San Francisco. The major changes in this version 
> of the draft include 
> 
> 1- Changing the document title to avoid confusion with other 
> ongoing "synchronization" drafts
> 
> 3- clarification of the RTCP message semantics, including 
> changes to the "Request" and "Inform" messages
> 
> 4- additional description/motivation for the various message 
> flows has been added
> 
> We hope to make this a Working Group item, and will change 
> the name of the draft to avoid conflicts with other 
> "synchronization" drafts at that time.
> 
>  
> 
> Bill VerSteeg
> 
>  
> 
>  
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 09:37:42 -0700

Hi Roni, 

> Behalf Of Roni Even
> Sent: Friday, April 24, 2009 4:24 AM
> To: [email-masked]
> Cc: Bill Ver Steeg (versteb)
> Multicast RTPSessions (RAMS)" available
> 
> Hi,
> 
> I think that the current draft does not give a description of 
> a system that works since there is no text explaining how the 

What do you mean by "a system that works"? 

> RS knows the unicast transport address on the RR to where to 
> send the stream. 

Once RS receives the request packet from an RR, RS knows its address. Ports are defined in the SDP. If you are asking about "NAT" issues, we have a section for it, and we plan to complete it as we move forward. It is not as critical as the other parts for now.
 
> If you mandate the use of RTP/RTCP mux it should say so 
> otherwise the RAMS-R should have an optional parameter that 
> supplies this information and a flag for using RTP/RTCP mux.

IMO, we cannot mandate muxing as it is not required to make RAMS work. If muxing is supported, the SDP should reflect it.

BR,
-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 21:44:01 +0300

Ali,
I will try to explain in simple way

When the RS receives the RAMS-R it need to start sending an RTP stream to
the RR. 
In order to send a unicast packet, the RS needs to know a transport address
on the RR to where the RTP stream will be sent. The current draft does not
say how the RS knows this address. There is no SDP from RR to RS like you
mention in your response.
This is why I say that the current draft does not specify a solution that
can be implemented as a working solution
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 7:38 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Hi Roni, 

> RS knows the unicast transport address on the RR to where to 

Once RS receives the request packet from an RR, RS knows its address. Ports
are defined in the SDP. If you are asking about "NAT" issues, we have a
section for it, and we plan to complete it as we move forward. It is not as
critical as the other parts for now.
 
> supplies this information and a flag for using RTP/RTCP mux.

IMO, we cannot mandate muxing as it is not required to make RAMS work. If
muxing is supported, the SDP should reflect it.

BR,
-acbegen
 
> http://www.ietf.org/internet-drafts/draft-versteeg-avt-rapid-s
ynchronization-for-rtp-03.txt <http://www.ietf.org/internet->
drafts/draft-versteeg-avt-rapid-synchronization-for-rtp-03.txt>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 24 Apr 2009 14:50:25 -0400

Roni-
 
Yes, the document needs updating in this respect. We have two broad
options which need to be described in detail.
 
The method that I have been assuming does use muxing. The RS sends the
unicast burst back to the UDP port number on the RR that sent the
RAMS-R. This allows transparent operation through NAT. There is a single
UDP port, and the transaction is initiated by the "client", so it is NAT
friendly.
 
There are quite a few ways we could handle the case in which muxing is
not used. We could add a parameter to the RAMS-R, use another RTCP
packet in the same compound packet, define the port numbers as a
relationship to the opened port (not attractive), or define something in
the SDP (also not attractive). I personally like the "RAMS-R optional
field" approach, but I think this should be a topic that we consider in
detail once we have a WG item.

 
bvs

________________________________

From: Roni Even [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 7:24 AM
To: [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP
Sessions (RAMS)" available

Hi,

I think that the current draft does not give a description of a system
that works since there is no text explaining how the RS knows the
unicast transport address on the RR to where to send the stream. 

If you mandate the use of RTP/RTCP mux it should say so otherwise the
RAMS-R should have an optional parameter that supplies this information
and a flag for using RTP/RTCP mux.

Thanks

Roni Even

 

Bill VerSteeg

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 12:00:51 -0700

Oh, I see. The burst goes to the port that we would normally send the retransmissions. For example, consider the SDP from the draft:

        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream #2
        c=IN IP4 224.1.1.2/255
        a=source-filter: incl IN IP4 224.1.1.2 192.0.2.2
        a=rtpmap:98 MP2T/90000
        a=rtcp:41001 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli
        a=ssrc:123321 cname:[email-masked]
        a=mid:3
        m=video 41002 RTP/AVPF 99
        i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=recvonly
        a=rtpmap:99 rtx/90000
        a=rtcp:41003
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4

In this case, the burst will go to port 41002 on the RR. The RAMS-I message(s), which is an RTCP feedback message, will go to port 41003.

HTH,
-acbegen

> Sent: Friday, April 24, 2009 11:44 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] New draft of "Rapid Acquisition of

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 22:19:04 +0300

Bill,

Since I have two hats here then as a WG chair, my intention is to ask the
list to start this topic as a WG item

Taking my WG chair off, my expectation is that a WG document will describe a
solution that can be implemented while the current text does not specify how
to make it work. I do not care if you write that RTP/RTCP mux MUST be used
by the RS and supported by the RR and update the SDP in the example to
specify that this is case.  

My personal preference is to have the RS indicate in the SDP that it wants
to use multiplexing and to add a flag to RAMS-R that will indicate if
RTP/RTCP mux is supported by RR and can be used. Only if the RR cannot
support the multiplexing it should indicate it using the flag and add to the
RAMS-R the transport address to be used (Note that it can be v4 or v6).

SDP cannot be used since there is no SDP from RR to RS.

Roni Even

From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 9:50 PM
To: Roni Even; [email-masked]
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions
(RAMS)" available

Roni-

Yes, the document needs updating in this respect. We have two broad options
which need to be described in detail.

The method that I have been assuming does use muxing. The RS sends the
unicast burst back to the UDP port number on the RR that sent the RAMS-R.
This allows transparent operation through NAT. There is a single UDP port,
and the transaction is initiated by the "client", so it is NAT friendly.

There are quite a few ways we could handle the case in which muxing is not
used. We could add a parameter to the RAMS-R, use another RTCP packet in the
same compound packet, define the port numbers as a relationship to the
opened port (not attractive), or define something in the SDP (also not
attractive). I personally like the "RAMS-R optional field" approach, but I
think this should be a topic that we consider in detail once we have a WG
item.

 

bvs

  _____  

From: Roni Even [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 7:24 AM
To: [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions
(RAMS)" available

Hi,

Thanks

Roni Even

 

Bill VerSteeg

---

From: "Roni Even" <[email-masked]>
Date: Fri, 24 Apr 2009 22:22:37 +0300

Ali,
I think you get it wrong, this SDP is from the RS and not the RR so the RS
cannot specify to which address it will send it can only specify to which
address it can receive RTP stream. In this SDP the relevant information is
that the request for retransmission will be sent by the RR to port 41003
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 10:01 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Oh, I see. The burst goes to the port that we would normally send the
retransmissions. For example, consider the SDP from the draft:

In this case, the burst will go to port 41002 on the RR. The RAMS-I
message(s), which is an RTCP feedback message, will go to port 41003.

HTH,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 24 Apr 2009 12:37:06 -0700

This is a part of an example SDP sent to RS and RR in a SAP announcement, for example. So, the SDP describes what both parties should do (RR cannot say that he wants to receive this multicast on its favorite port). The individual SDPs sent to RR or RS may include other portions of descriptions that will contain specific information. 

-acbegen

> Sent: Friday, April 24, 2009 12:23 PM

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 24 Apr 2009 15:37:11 -0400

Roni-
 
These are reasonable approaches, which I need to consider in detail. I
have (mostly) been thinking about NAT-friendly solutions, which leads me
back to muxing. I need to consider the ramifications of NAT on the
methods that signal IP addresses and port numbers as part of the
run-time for acceleration. The intent is to make acquisition faster, and
additional complexity at session instantiation should be avoided (IMHO).
 
More to come, once I get my head around the various options.
 
bvs

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Friday, April 24, 2009 3:19 PM
To: Bill Ver Steeg (versteb); [email-masked]
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast
RTPSessions (RAMS)" available

Bill,

Since I have two hats here then as a WG chair, my intention is to ask
the list to start this topic as a WG item

Taking my WG chair off, my expectation is that a WG document will
describe a solution that can be implemented while the current text does
not specify how to make it work. I do not care if you write that
RTP/RTCP mux MUST be used by the RS and supported by the RR and update
the SDP in the example to specify that this is case.  

My personal preference is to have the RS indicate in the SDP that it
wants to use multiplexing and to add a flag to RAMS-R that will indicate
if RTP/RTCP mux is supported by RR and can be used. Only if the RR
cannot support the multiplexing it should indicate it using the flag and
add to the RAMS-R the transport address to be used (Note that it can be
v4 or v6).

Roni Even

Roni-

 

bvs

Hi,

Thanks

Roni Even

 

Bill VerSteeg

---

From: Zou ZiXuan <[email-masked]>
Date: Sat, 25 Apr 2009 09:23:41 +0800

Hi, Ali,
	Thanks for your explanation. 

> Sent: Friday, April 24, 2009 11:13 PM
> To: Zou ZiXuan; Bill Ver Steeg (versteb); [email-masked]
Sessions
> Per RFC 3550, each SSRC space has its own clock rate and seq
numbering.
> We include the SSRC in the RAMS request messages.
> 
> There are different flavors of your scneario. Lets assume that we have
two
> RTP streams (audio and video).
> 
> 
> Here, we run a different independent RAMS session for each RTP stream
> that we want to rapidly acquire (they can run in parallel). Here one
needs to
> pay attention to how to use the shared bandwidth among different
bursts,
> though.
> 
> Case 2: Different RTP sessions are transmitted over the same mcast
group
> (with different dest ports).
> 
> Again, we run a different independent RAMS for each RTP stream
(different
> request for each, etc). But, one should keep in mind that the join
times for the
> all RAMS sessions need to be common as there is only one multicast.
> 
> Case 3: One RTP session (same mcast group, same dest port) carrying
both
> audio and video (this is SSRC multiplexing).
> 
> Similar to case 2, join time needs to be coordinated among different
RAMS
> sessions running for each RTP stream. Since we signal SSRC in the
request
> message and we have independent RAMS sessions, using different clock
> rates is not an issue.
> 
> Case 4: One RTP session, one SSRC with payload type multiplexing. This
is
> not recommended for many reasons. On top of that, different payloads
with
> different clock rates cannot be multiplexed in this fashion. So, I
don't think this
> will apply to our problem.
> 
> HTH,
> -acbegen
> 
>

---

From: "Roni Even" <[email-masked]>
Date: Sat, 25 Apr 2009 14:08:27 +0300

Ali,
The example SDP is syntactically correct but it does not say that the
rtp/rtcp mux will be used and it does not give the information to where the
unicast stream will be sent when the RR sends a RAMS-R. 

I am not sure why the unicast stream m-line has a port number with an
attribute of recvonly. What is the use case for that. The only information
that the RR will need is the RTCP port on the RS to where to send the RAMS-R
message.
Roni
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Friday, April 24, 2009 10:37 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

This is a part of an example SDP sent to RS and RR in a SAP announcement,
for example. So, the SDP describes what both parties should do (RR cannot
say that he wants to receive this multicast on its favorite port). The
individual SDPs sent to RR or RS may include other portions of descriptions
that will contain specific information. 

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 25 Apr 2009 13:02:13 -0700

> unicast stream will be sent when the RR sends a RAMS-R. 

To my knowledge, the first line in the following SDP tells the RRs on which port they will receive the retransmission/burst packets.

There is a typo, you are right. That "a=recvonly" line should only exist in the SDP sent to RRs. In the SDP sent to RS, we should rather have "a=sendonly". I will make this correction in the next version.

The feedback target for the SSM session and the RTCP port for the retransmission session are also defined in the SDP.

Hope this clarifies.

BR,
-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Sat, 25 Apr 2009 23:11:28 +0300

Ali,
Can you please write three addresses from this strange SDP.

1. The address and port of multicast

2. The address and port of the RS where the RTCP FB should go to

3. The address and port on the RR where the unicast stream should be sent to

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Saturday, April 25, 2009 11:02 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

> unicast stream will be sent when the RR sends a RAMS-R. 

To my knowledge, the first line in the following SDP tells the RRs on which
port they will receive the retransmission/burst packets.

There is a typo, you are right. That "a=recvonly" line should only exist in
the SDP sent to RRs. In the SDP sent to RS, we should rather have
"a=sendonly". I will make this correction in the next version.

The feedback target for the SSM session and the RTCP port for the
retransmission session are also defined in the SDP.

Hope this clarifies.

BR,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 25 Apr 2009 13:30:19 -0700

Here is the SDP.

Source (192.0.2.2) sends the rtp packets to the multicast group (224.1.1.2) with a dest port 41000.

        a=rtpmap:98 MP2T/90000

The feedback target (RS) address for this SSM session is 192.0.2.1 and its port is 41001. This is the address/port where RR sends the RAMS-R, or receiver reports for the SSM session.

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli

The retransmission packets go to port 41002. This is the port RRs listen to for retransmission and RAMS.

This is where the retransmission packets come from, same as the feedback target (in this example).

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

This is where the RTCP packets for the retransmission session go. For example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on RS.

-acbegen

> Sent: Saturday, April 25, 2009 1:11 PM

---

From: "Roni Even" <[email-masked]>
Date: Sun, 26 Apr 2009 00:24:00 +0300

Ali,
See inline
Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Saturday, April 25, 2009 11:30 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Here is the SDP.

Source (192.0.2.2) sends the rtp packets to the multicast group (224.1.1.2)
with a dest port 41000.

        a=rtpmap:98 MP2T/90000

The feedback target (RS) address for this SSM session is 192.0.2.1 and its
port is 41001. This is the address/port where RR sends the RAMS-R, or
receiver reports for the SSM session.

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli

The retransmission packets go to port 41002. This is the port RRs listen to
for retransmission and RAMS.

Roni E: This implies that the multicast source defines the port that all
clients MUST use to receive the unicast information from the Burst source.  

This is where the retransmission packets come from, same as the feedback
target (in this example).

Roni E: If this is the address of the feedback target it belongs to the
above m-line (m=video 41002 RTP/AVPF 99) that according to you gives the
port on the RR and not on the RS. The problem is that according to SDP the
combination of the c= and port on the m-line provides the transport address
to where a stream will be sent so according to SDP this m-line specify an
address and port on the Feedback Target and not on the RR and only to this
address RTP payload type 99 will be sent. I am positive that this is not
what you want.

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

This is where the RTCP packets for the retransmission session go. For
example, RAMS-I goes to this port on RRs. RAMS-T goes to this port on RS.

Roni E: So now you assume that the RR must use the same port as the FT for
this communication. I could not find any place that one m-line gives the
address for both sides. This RTCP port is on 192.0.2.1 so it will be used
for RAMS-R but not for RAMS-I.

-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Sun, 26 Apr 2009 00:34:51 +0300

Ali,
Another comment
I thought that RAMS-R and RAMS-T go to the same port but in the example you
say that RAMS-R go to port 41001 and RAMS-T go to port 41003

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Saturday, April 25, 2009 11:30 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Here is the SDP.

        a=rtpmap:98 MP2T/90000

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Sun, 26 Apr 2009 00:57:46 +0300

Ali,
I looked at RFC 4570 and I assume that port 41001 is the port for the
unicast RTCP reports from the receivers and according to section 3.2.1 of
that RFC you also should have a RTCP-unicast specification. This is for the
multicast receiver reports.

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Saturday, April 25, 2009 11:30 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Here is the SDP.

        a=rtpmap:98 MP2T/90000

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack ssli

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 25 Apr 2009 15:23:17 -0700

Inline.

> clients MUST use to receive the unicast information from the 

Yes, that is what it implies (One nit is that I would call it unicast RTP packets rather than information since we may use another port for RTCP packets).
 
> port on the RR and not on the RS. The problem is that 

This line actually specifies the sender for the unicast retransmission session. In our case, it just happens to be the feedback target for the primary SSM session, too. I recall some discussion about using a retransmission source which is different than the feedback target for the SSM. In that case, the address would be different, I guess.

> according to SDP the
> to where a stream will be sent so according to SDP this 

The port on the m line is the port where the retranmission packets are sent. However, c line denotes the source for these packets. RFC 4566 page 13 says that "... If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields..."

Am I missing something?

> m-line specify an

There can be other payload types we might need to send on this retransmission session in the future. In that case, we will add them.
 
> this communication. I could not find any place that one 

Not the m line, but the "a=rtcp" line. Is this wrong?

> for RAMS-R but not for RAMS-I.

RAMS-R should go to the feedback target address and port for the primary SSM session since it is a feedback message for the SSM session. But, RAMS-T is a feedback message for the retransmission session, thus, it should go to the RTCP port of the retransmission session (41003). I hope this also clarifies your question in the next email. If you think I got the ports wrong, let me know.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 25 Apr 2009 15:26:44 -0700

> Sent: Saturday, April 25, 2009 2:58 PM
> unicast RTCP reports from the receivers and according to

Yes, indeed.
 
> section 3.2.1 of

Correct. We do have that line in our draft at the top right after the grouping lines:

	a=rtcp-unicast:rsi

BR,
-acbegen

---

From: "Roni Even" <[email-masked]>
Date: Sun, 26 Apr 2009 11:14:07 +0300

Ali,
I looked at RTSP
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-20#appendix-D 

D.1.2.  Media Streams

   The "m=" field is used to enumerate the streams.  It is expected that
   all the specified streams will be rendered with appropriate
   synchronization.  If the session is over multicast, the port number
   indicated SHOULD be used for reception.  The client MAY try to
   override the destination port, through the Transport header.  The
   servers MAY allow this, the response will indicate if allowed or not.
   If the session is unicast, the port numbers are the ones RECOMMENDED
   by the server to the client, about which receiver ports to use; the
   client MUST still include its receiver ports in its SETUP request.
   The client MAY ignore this recommendation.  If the server has no
   preference, it SHOULD set the port number value to zero.

Note that the client has the choice on which port to receive the unicast
stream, this is why there should be such a parameter in RAMS-R

Also

" D.1.8.  Connection Information

   In SDP, the "c=" field contains the destination address for the media
   stream.  For on-demand unicast streams and some multicast streams,
   the destination address MAY be specified by the client via the SETUP
   request, thus overriding any specified address.  To identify streams
   without a fixed destination address, where the client is required to
   specify a destination address, the "c=" field SHOULD be set to a null
   value.  For addresses of type "IP4", this value MUST be "0.0.0.0",
   and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be
   written as "::"), i.e. the unspecified address according to RFC 4291
   [RFC4291]."

As for the c-line in the unicast stream the whole section you quoted

" If the session is multicast, the connection address will be an IP
      multicast group address.  If the session is not multicast, then
      the connection address contains the unicast IP address of the
      expected data source or data relay or data sink as determined by
      additional attribute fields.  It is not expected that unicast
      addresses will be given in a session description that is
      communicated by a multicast announcement, though this is not
      prohibited."

Now the expectation here is for the address of the stream described by the
port in the m-line, I do not see any other attribute. Also look at the above
text from RTSP. The RS does not know the IP address on the RR to where to
send the RTP unicast repair stream. If you assume it is to the IP address
from where the RTCP RAMS-R came from this is not mandated that the client
will have such implementation. Furthermore the address that the RS will see
in the received RTCP RAMS-R packet may have been change by a NAT or SBC.

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Sunday, April 26, 2009 1:23 AM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Inline.

> clients MUST use to receive the unicast information from the 

Yes, that is what it implies (One nit is that I would call it unicast RTP
packets rather than information since we may use another port for RTCP
packets).
 
> port on the RR and not on the RS. The problem is that 

This line actually specifies the sender for the unicast retransmission
session. In our case, it just happens to be the feedback target for the
primary SSM session, too. I recall some discussion about using a
retransmission source which is different than the feedback target for the
SSM. In that case, the address would be different, I guess.

> to where a stream will be sent so according to SDP this 

The port on the m line is the port where the retranmission packets are sent.
However, c line denotes the source for these packets. RFC 4566 page 13 says
that "... If the session is not multicast, then the connection address
contains the unicast IP address of the expected data source or data relay or
data sink as determined by additional attribute fields..."

Am I missing something?

> address RTP payload type 99 will be sent. I am positive that 

There can be other payload types we might need to send on this
retransmission session in the future. In that case, we will add them.

> for RAMS-R but not for RAMS-I.

RAMS-R should go to the feedback target address and port for the primary SSM
session since it is a feedback message for the SSM session. But, RAMS-T is a
feedback message for the retransmission session, thus, it should go to the
RTCP port of the retransmission session (41003). I hope this also clarifies
your question in the next email. If you think I got the ports wrong, let me
know.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 26 Apr 2009 10:02:24 -0700

Hi Roni,

Thanks for the detailed answer. Admittedly, I don't know much about RTSP beyond its basics. However, I doubt how much it applies in our case. "Unicast" in RTSP context mostly refers to video-on-demand kind of applications where the primary distribution is over unicast. In contrast, our primary distribution is over multicast, and we use unicast as a repair stream. Thus, I still believe the SDP we have should work fine. RS gathers the IP address of the RR when it receives the RAMS request. The samething happens when RR sends a NACK for requesting retransmissions.

That is not to say that this SDP is the only SDP that will work in this system. There may be others. But, I still don't agree with you when you say that this SDP won't work. My expectation is that we will include other SDP examples as we move forward.

On your last point, NAT is a different issue and there has to be a way to deal with it. Muxing sounds reasonable, and we may or may not mandate it, I am not sure at this point. An alternative could be that RR opens ports on its NAT device and includes them in the request message it sends. These could be in RAMS-R TLV extensions, or could be a separate RTCP packet solely for this purpose within the same RTCP compound packet that carries the RAMS-R. I believe Bill mentioned these briefly in his earlier email. We are open to suggestions at this point and the NAT section will cover these issues once we have a WG item.

-acbegen

> Sent: Sunday, April 26, 2009 1:14 AM
> > > > > > say how the RS knows this address. There is no SDP 
> from RR to 
> > > > > > RS like you
> > > > > > Once RS receives the request packet from an RR, RS 
> knows its 
> > > > > > address. Ports
> > > > > > are defined in the SDP. If you are asking about 
> "NAT" issues, 
> > > > > > we have a

---

From: "Roni Even" <[email-masked]>
Date: Sun, 26 Apr 2009 21:48:12 +0300

Ali,
Your SDP example will not help anyone who will try to develop interop
application, the c-line in the unicast stream and the port should refer to
the same device since there is no other attribute in the example that points
to a different semantics to anyone who will look at it. The semantics that
you are using where the c-line is for the RS and the port is for the RR and
the RS assuming that the RS somehow knows the IP address of the RR based on
the RAMS-R request may work in some cases but should not be the one shown as
the primary example and should not be the recommended way, The recommended
way should be to convey the address of the RR in the RAMS-R and this is the
reason I pointed to RTSP. The semantics of the SDP in the example is not
documented in your text and is not obvious to anyone who will just look at
it.
   
I also strongly object to mandating that the client MUST use a port defined
by the server to receive the unicast stream. The RS can recommend a port but
it is the client (RR) decision to decide which port to use.

Roni Even

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Sunday, April 26, 2009 8:02 PM
To: Roni Even; [email-masked]
Cc: Bill Ver Steeg (versteb)
Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Hi Roni,

Thanks for the detailed answer. Admittedly, I don't know much about RTSP
beyond its basics. However, I doubt how much it applies in our case.
"Unicast" in RTSP context mostly refers to video-on-demand kind of
applications where the primary distribution is over unicast. In contrast,
our primary distribution is over multicast, and we use unicast as a repair
stream. Thus, I still believe the SDP we have should work fine. RS gathers
the IP address of the RR when it receives the RAMS request. The samething
happens when RR sends a NACK for requesting retransmissions.

That is not to say that this SDP is the only SDP that will work in this
system. There may be others. But, I still don't agree with you when you say
that this SDP won't work. My expectation is that we will include other SDP
examples as we move forward.

On your last point, NAT is a different issue and there has to be a way to
deal with it. Muxing sounds reasonable, and we may or may not mandate it, I
am not sure at this point. An alternative could be that RR opens ports on
its NAT device and includes them in the request message it sends. These
could be in RAMS-R TLV extensions, or could be a separate RTCP packet solely
for this purpose within the same RTCP compound packet that carries the
RAMS-R. I believe Bill mentioned these briefly in his earlier email. We are
open to suggestions at this point and the NAT section will cover these
issues once we have a WG item.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 26 Apr 2009 18:54:14 -0700

Roni,

> application, the c-line in the unicast stream and the port 

I believe this is rather a strong claim, considering that I already mentioned that we would add more SDP examples as we moved forward.

> should refer to
> the primary example and should not be the recommended way, 

Again, you are missing the point that we will add more SDP examples as well as discussion for NAT issues. The current SDP is just one example that we came up with, and which, I believe, still works and has been there since version -00. It may be modified, removed or replaced.

> The recommended
> reason I pointed to RTSP. The semantics of the SDP in the 

This is reasonable, rtp/rtcp muxing is also reseanoable and it is indeed very neat, too. 

> example is not

We can certainly add more detailed explanation to the SDP section. But, let's focus more on the draft rather than a single SDP example that it currently has.
    
> it is the client (RR) decision to decide which port to use.

We are not mandating anything yet as I mentioned several times before. I suggest we drop this discussion and move forward with the draft. Based on the comments/suggestions that may be sent to your email about the SDP example, we will be more than happy to incorporate what AVT decides to do.

-acbegen
 
> > > > > > I think you get it wrong, this SDP is from the RS 
> and not the 
> > > > > > RR so the RS
> > > > > > that the request for retransmission will be sent by 
> the RR to 
> > > > > > port 41003
> > > > > > Roni
> > > > > > 
> > > > > > > When the RS receives the RAMS-R it need to start 
> sending an 
> > > > > > > RTP stream to
> > > > > > > the RR. 
> > > > > > > on the RR to where the RTP stream will be sent. 
> The current 
> > > > > > > draft does not
> > > > > > > This is why I say that the current draft does not 
> specify a 
> > > > > > > solution that
> > > > > > > IMO, we cannot mandate muxing as it is not 
> required to make 
> > > > > > > RAMS work. If