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

From: José Rey <[email-masked]>
Date: Fri, 22 May 2009 00:22:06 +0200

Hi all,

sorry for jumping in....
 
I think one of the sources of confusion is that the attribute a=rtcp: is 
used once for specifying the destination port  and once for specifying a 
receiving port, and in the same SDP (!). The destination port for RAMS-I 
packets sent by RS and the receiving port for RAMS-T. Which is also why 
different port numbers are used for RAMS-T and -R packets.

I think the use of a=rtcp: in SSM is the problem here. Or the fact that 
we are mixing unicast and multicast, or both.

Hope this helps,

JLR

Ali C. Begen (abegen) wrote:
>  
>
>   
>> -----Original Message-----
>> From: Roni Even [mailto:[email-masked]] 
>> Sent: Saturday, April 25, 2009 2:58 PM
>> To: Ali C. Begen (abegen); [email-masked]
>> Cc: Bill Ver Steeg (versteb)
>> Subject: RE: [AVT] New draft of "Rapid Acquisition of 
>> Multicast RTPSessions (RAMS)" available
>>
>> 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
>>     
>
> Yes, indeed.
>  
>   
>> section 3.2.1 of
>> that RFC you also should have a RTCP-unicast specification. 
>> This is for the
>> multicast receiver reports.
>>     
>
> Correct. We do have that line in our draft at the top right after the grouping lines:
>
> 	a=rtcp-unicast:rsi
>
> BR,
> -acbegen
>  
>   
>> 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.
>>
>>         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
>>
>> 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
>>         a=rtcp:41001 IN IP4 192.0.2.1
>>
>> 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
>>         a=ssrc:123321 cname:[email-masked]
>>         a=mid:3
>>         m=video 41002 RTP/AVPF 99
>>
>> The retransmission packets go to port 41002. This is the port 
>> RRs listen to
>> for retransmission and RAMS.
>>
>>         i=Unicast Retransmission Stream #2 (Ret. and Rapid 
>> Acq. Support)
>>         c=IN IP4 192.0.2.1
>>
>> 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.
>>
>>         a=fmtp:99 apt=98; rtx-time=5000
>>         a=mid:4
>>
>>
>> -acbegen
>>  
>>
>>     
>>> -----Original Message-----
>>> From: Roni Even [mailto:[email-masked]] 
>>> Sent: Saturday, April 25, 2009 1:11 PM
>>> To: Ali C. Begen (abegen); [email-masked]
>>> Cc: Bill Ver Steeg (versteb)
>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of 
>>> Multicast RTPSessions (RAMS)" available
>>>
>>> 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
>>>
>>>       
>>>> 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. 
>>>>         
>>> To my knowledge, the first line in the following SDP tells 
>>> the RRs on which
>>> port they will receive the retransmission/burst packets.
>>>
>>>         m=video 41002 RTP/AVPF 99
>>>         i=Unicast Retransmission Stream #2 (Ret. and Rapid 
>>> Acq. Support)
>>>         c=IN IP4 192.0.2.1
>>>         a=rtpmap:99 rtx/90000
>>>         a=rtcp:41003
>>>         a=fmtp:99 apt=98; rtx-time=5000
>>>         a=mid:4
>>>
>>> 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
>>>  
>>>       
>>>> 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
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Roni Even [mailto:[email-masked]] 
>>>>> Sent: Friday, April 24, 2009 12:23 PM
>>>>> To: Ali C. Begen (abegen); [email-masked]
>>>>> Cc: Bill Ver Steeg (versteb)
>>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of 
>>>>> Multicast RTPSessions (RAMS)" available
>>>>>
>>>>> 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:
>>>>>
>>>>>         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
>>>>>
>>>>>           
>>>>>> -----Original Message-----
>>>>>> From: Roni Even [mailto:[email-masked]] 
>>>>>> Sent: Friday, April 24, 2009 11:44 AM
>>>>>> To: Ali C. Begen (abegen); [email-masked]
>>>>>> Cc: Bill Ver Steeg (versteb)
>>>>>> Subject: RE: [AVT] New draft of "Rapid Acquisition of 
>>>>>> Multicast RTPSessions (RAMS)" available
>>>>>>
>>>>>> 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, 
>>>>>>
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>>>>> Behalf Of Roni Even
>>>>>>> Sent: Friday, April 24, 2009 4:24 AM
>>>>>>> To: [email-masked]
>>>>>>> Cc: Bill Ver Steeg (versteb)
>>>>>>> Subject: Re: [AVT] New draft of "Rapid Acquisition of 
>>>>>>> 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
>>>>>>  
>>>>>>             
>>>>>>> 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-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
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>             
>>>>>           
>>>>         
>>>       
>>     
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 21 May 2009 16:59:54 -0700

Hi Jose,

We have separate RTCP ports for the SSM session and the unicast session. Why is it a problem?

The slightly modified SDP for the next version is below:

        a=group:FID 3 4
        a=rtcp-unicast:rsi
        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream #2
        c=IN IP4 233.252.0.2/255
        a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
        a=recvonly
        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

This is the SDP we send to RR. For RS, a=recvonly will be a=sendonly.

-acbegen

> From: José Rey [mailto:[email-masked]]
> Sent: Thursday, May 21, 2009 3:22 PM
> To: Ali C. Begen (abegen)
> Cc: Roni Even; [email-masked]; Bill Ver Steeg (versteb)
> Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)"
> available
> 
> Hi all,
> 
> sorry for jumping in....
> 
> I think one of the sources of confusion is that the attribute a=rtcp: is used once for
> specifying the destination port  and once for specifying a receiving port, and in the same
> SDP (!). The destination port for RAMS-I packets sent by RS and the receiving port for
> RAMS-T. Which is also why different port numbers are used for RAMS-T and -R packets.
> 
> I think the use of a=rtcp: in SSM is the problem here. Or the fact that we are mixing
> unicast and multicast, or both.
> 
> Hope this helps,
> 
> JLR
> 
> 
> 
> 
> 						ynchronization-for-rtp-03.txt
> <http://www.ietf.org/internet-> <http://www.ietf.org/internet->
> 
> 
>

---

From: "Jose Rey" <[email-masked]>
Date: Fri, 22 May 2009 16:09:20 +0200

Hi Ali,

> unicast session. Why is it a problem?

In line 19 you say you specify the dst port for RMS-I (41003), on RR. And you say that would also be the port where the RR sends RMS-T, on RS. That is mixing the semantics of a=rtcp for SSM (listening port at Feedback Target = mcast RTCP dst port) and those of RFC 3605 (dst port). In other words, you are implicitly assuming that specifies symmetric RTCP...no?

Another thing that was mentioned already:  RMS-T is not sent to same port as RMS-R; is it not the same RTCP session ? Or is this muxing desired? why?
 
JLR
 
> The slightly modified SDP for the next version is below:
1>         a=group:FID 3 4
2>         a=rtcp-unicast:rsi
3>         m=video 41000 RTP/AVPF 98
4>         i=Primary Multicast Stream #2
5>         c=IN IP4 233.252.0.2/255
6>         a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
7>         a=recvonly
8>         a=rtpmap:98 MP2T/90000
9>         a=rtcp:41001 IN IP4 192.0.2.1
10>         a=rtcp-fb:98 nack
11>         a=rtcp-fb:98 nack ssli
12>         a=ssrc:123321 cname:[email-masked]
13>         a=mid:3
14>         m=video 41002 RTP/AVPF 99
15>         i=Unicast Retransmission Stream #2 (Ret. and Rapid 
>           Acq. Support)
16>         c=IN IP4 192.0.2.1
17>         a=recvonly
18>         a=rtpmap:99 rtx/90000
19>         a=rtcp:41003
20>         a=fmtp:99 apt=98; rtx-time=5000
21>         a=mid:4
> > I think one of the sources of confusion is that the 
> attribute a=rtcp: 
> > is used once for specifying the destination port  and once for 
> > specifying a receiving port, and in the same SDP (!). The 
> destination 
> > port for RAMS-I packets sent by RS and the receiving port 
> for RAMS-T. Which is also why different port numbers are used 
> for RAMS-T and -R packets.
> > 
> > I think the use of a=rtcp: in SSM is the problem here. Or the fact 
> > that we are mixing unicast and multicast, or both.
> > 
> > Hope this helps,
> > 
> > JLR
> > 
> > 
> > 
> > 
> > 					I think you get it 
> wrong, this SDP is from the RS and not the
> > 					RR so the RS
> > 					cannot specify to which 
> > 					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
> > 					        
> > 					        m=video 41002 
> RTP/AVPF 99
> > 						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 
> > 							From: 
> [email-masked] [mailto:avt- [email-masked]] On
> > 							Behalf 
> Of Roni Even
> > 							Sent: 
> > 							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, 
> > 							If you 
> mandate the use of RTP/RTCP mux it should say so
> > 							
> > 						IMO, we cannot 
> mandate muxing as it is not required to make
> > 						RAMS work. If
> > 						muxing is 
> > 							From: 
> [email-masked] [mailto:avt- [email-masked]] On
> > 							Behalf 
> > 							There 
> is a new draft of the "Rapid Acquisition of Multicast
> > 							RTP 
> > 							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 
> > 							4- 
> additional description/motivation for the
> > 
> > 
> > 		various message
> > 
> > 
> > 							flows 
> has been added
> > 
> > 							5- 
> > 							We hope 
> to make this a Working Group item, and will change
> > 							the 
> name of the draft to avoid conflicts with other
> > 							

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 22 May 2009 17:26:36 -0700

Hi Jose,

Indeed, RAMS-R goes to the FT of the new primary session that RR is interested in acquiring rapidly. Then the unicast session becomes alive and RS sends RAMS-I message(s) to RR on the RTCP port for the unicast session. After some time, RR sends the RAMS-T message to the RTCP port for the unicast session since it is supposed to end the unicast session. 

-acbegen

> From: Jose Rey [mailto:[email-masked]]
> Sent: Friday, May 22, 2009 7:09 AM
> Subject: RE: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)"
> available
> 
> 
> Hi Ali,
> 
> >
> > Hi Jose,
> >
> In line 19 you say you specify the dst port for RMS-I (41003), on RR. And you say that
> would also be the port where the RR sends RMS-T, on RS. That is mixing the semantics of
> a=rtcp for SSM (listening port at Feedback Target = mcast RTCP dst port) and those of RFC
> 3605 (dst port). In other words, you are implicitly assuming that specifies symmetric
> RTCP...no?
> 
> Another thing that was mentioned already:  RMS-T is not sent to same port as RMS-R; is it
> not the same RTCP session ? Or is this muxing desired? why?
> 
> JLR
> 
> >
> > Of Bill Ver Steeg (versteb)
> > > 							Sent:

---

From: Roni Even <[email-masked]>
Date: Sat, 23 May 2009 15:18:32 +0300

Hi,
I also have concerns about having the unicast Transport addresses for the RR
RTCP and RTP receive port.
I think that we should first talk about the NAT/FW issue and than define the
requirements and solutions.

My assumption is that the retransmission server has a publicly reachable
address while the receivers may sit behind NATs and will not have a publicly
reachable address.
Note that the RAMS flow starts from the receiver by RAMS-R so a response to
the transport address from where the RAMS-R came should work (RTCP is
bi-directional in this case). On the other hand the unicast data flow is to
the receiver so the receiver will need to provide a reachable transport
address.

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Saturday, May 23, 2009 3:27 AM
To: Jose Rey
Cc: Roni Even; [email-masked]; Bill Ver Steeg (versteb)
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

Hi Jose,

Indeed, RAMS-R goes to the FT of the new primary session that RR is
interested in acquiring rapidly. Then the unicast session becomes alive and
RS sends RAMS-I message(s) to RR on the RTCP port for the unicast session.
After some time, RR sends the RAMS-T message to the RTCP port for the
unicast session since it is supposed to end the unicast session. 

-acbegen

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Sun, 24 May 2009 06:01:46 -0400

Roni-
Regarding the RS being able to send data to the RR after receiving a RAMS-R.

There is a subtle point here, which you reference in your comment "need to provide a reachable transport address". The RR sends the RAMS-R to the feedback target UDP port number. In the presence of NAT, the only communication path that is opened automatically is that single path. In order to use the other port-pairs, holes must be poked in the NAT and the correct NAT-ed ports must be signaled. As you know, there are many ways to poke wholes in NAT, so we will not go into the details of how to do that.

This is an important point, and we will be sure to make it more clear in the next draft.

Bvs

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

Hi,
I also have concerns about having the unicast Transport addresses for the RR RTCP and RTP receive port.
I think that we should first talk about the NAT/FW issue and than define the requirements and solutions.

My assumption is that the retransmission server has a publicly reachable address while the receivers may sit behind NATs and will not have a publicly reachable address.
Note that the RAMS flow starts from the receiver by RAMS-R so a response to the transport address from where the RAMS-R came should work (RTCP is bi-directional in this case). On the other hand the unicast data flow is to the receiver so the receiver will need to provide a reachable transport address.

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C.
Begen (abegen)
Sent: Saturday, May 23, 2009 3:27 AM
To: Jose Rey
Cc: Roni Even; [email-masked]; Bill Ver Steeg (versteb)
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions (RAMS)" available

Hi Jose,

Indeed, RAMS-R goes to the FT of the new primary session that RR is interested in acquiring rapidly. Then the unicast session becomes alive and RS sends RAMS-I message(s) to RR on the RTCP port for the unicast session.
After some time, RR sends the RAMS-T message to the RTCP port for the unicast session since it is supposed to end the unicast session. 

-acbegen

> In line 19 you say you specify the dst port for RMS-I (41003), on RR. 
> And
you say that
> would also be the port where the RR sends RMS-T, on RS. That is mixing 
> the
semantics of
> a=rtcp for SSM (listening port at Feedback Target = mcast RTCP dst 
> port)
and those of RFC
> Another thing that was mentioned already:  RMS-T is not sent to same 
> port
as RMS-R; is it
> > for RAMS-T. Which is also why different port numbers are used for 
> > RAMS-T and -R packets.
> > >

---

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

Bill,
My major point here is this is a reason for having an option port or
transport address parameter in the RAMS-R allowing the RR to provide such
address.
Roni

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

Roni-

There is a subtle point here, which you reference in your comment "need to
provide a reachable transport address". The RR sends the RAMS-R to the
feedback target UDP port number. In the presence of NAT, the only
communication path that is opened automatically is that single path. In
order to use the other port-pairs, holes must be poked in the NAT and the
correct NAT-ed ports must be signaled. As you know, there are many ways to
poke wholes in NAT, so we will not go into the details of how to do that.

This is an important point, and we will be sure to make it more clear in the
next draft.

Bvs

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

Hi,

Roni

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

Hi Jose,

-acbegen

you say that
semantics of
and those of RFC
as RMS-R; is it

---

From: David R Oran <[email-masked]>
Date: Sun, 24 May 2009 09:59:56 -0400

> transport address parameter in the RAMS-R allowing the RR to provide  
Correct, in principle. I've already commented on the problematic  
nature of sending complete transport addresses, so my strong  
preference would be only to communicate port numbers (and possibly  
SSRCs)

However it's an interesting design point whether this situation is so  
unique to RAMS that we solve it by putting the information in RAMS-R  
messages, or whether it justifies a more general-purpose mechanism.

An alternative design would be to define a separate RTCP packet type  
to carry transport port information for "auxiliary" unicast RTP/RTCP  
sessions. The situation we face with RAMS does in fact may arise in  
other situations, both with and without NAT, where separate signaling  
using offer/answer (as SIP would do) is either overkill, too much  
overhead, or bad from a latency perspective. Just think unicast  
retransmission for SSM by itself, without RAMS.

In my view, it would be worth having a serious WG discussion of this  
general subject before plunging ahead. If the sense is to in fact have  
a separate mechanism, I have one sitting in my back pocket (and have  
running open source code for).

DaveO.

---

From: Roni Even <[email-masked]>
Date: Sun, 24 May 2009 20:33:35 +0300

Dave,
I will start a separate thread on the issue. Just note that port may not be
enough, an example is if the RR is using a TURN relay
Roni

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Sunday, May 24, 2009 5:00 PM
To: Roni Even
Cc: 'Bill Ver Steeg (versteb)'; 'Roni Even'; 'Ali C. Begen (abegen)'; 'Jose
Rey'; [email-masked]

DaveO.

---

From: David R Oran <[email-masked]>
Date: Mon, 25 May 2009 12:31:11 -0400

> enough, an example is if the RR is using a TURN relay
Stopping reflection attacks here is more difficult - it requires STUN  
cookies and the possibility of opening up state-based attacks on the  
retransmission server. If that's the way the WG wants to go I'm ok  
with that, but this is one area in which I might go to the IESG and  
get some sense of whether we would run into a buzz-saw at the end  
after investing a lot of design and consensus effort.

---

From: Roni Even <[email-masked]>
Date: Mon, 25 May 2009 22:38:24 +0300

Dave,
What I am trying to understand is what are the assumptions in this solution.
I will not object to any assumption as long as it is stated. 
Roni Even
As individual

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David
R Oran
Sent: Monday, May 25, 2009 7:31 PM
To: Roni Even
Cc: 'Roni Even'; 'Jose Rey'; [email-masked]; 'Bill Ver Steeg (versteb)'
Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTPSessions
(RAMS)" available

On May 24, 2009, at 1:33 PM, Roni Even wrote:

> Dave,
> I will start a separate thread on the issue. Just note that port may 
> not be enough, an example is if the RR is using a TURN relay
Stopping reflection attacks here is more difficult - it requires STUN
cookies and the possibility of opening up state-based attacks on the
retransmission server. If that's the way the WG wants to go I'm ok with
that, but this is one area in which I might go to the IESG and get some
sense of whether we would run into a buzz-saw at the end after investing a
lot of design and consensus effort.

> Cc: 'Bill Ver Steeg (versteb)'; 'Roni Even'; 'Ali C. Begen (abegen)'; 
> 'Jose Rey'; [email-masked]
>> transport address parameter in the RAMS-R allowing the RR to provide 
>> such address.
>> There is a subtle point here, which you reference in your comment 
>> "need to provide a reachable transport address". The RR sends the 
>> RAMS-R to the feedback target UDP port number. In the presence of 
>> NAT, the only communication path that is opened automatically is that 
>> single path.
>> In
>> order to use the other port-pairs, holes must be poked in the NAT and 
>> the correct NAT-ed ports must be signaled. As you know, there are 
>> many ways to poke wholes in NAT, so we will not go into the details 
>> of how to do that.
>>
>> My assumption is that the retransmission server has a publicly 
>> reachable address while the receivers may sit behind NATs and will 
>> not have a publicly reachable address.
>> Note that the RAMS flow starts from the receiver by RAMS-R so a 
>> response to the transport address from where the RAMS-R came should 
>> work (RTCP is bi-directional in this case). On the other hand the 
>> unicast data flow is to the receiver so the receiver will need to 
>> provide a reachable transport address.
>>
>> Roni
>>
>> interested in acquiring rapidly. Then the unicast session becomes 
>> alive and RS sends RAMS-I message(s) to RR on the RTCP port for the 
>> unicast session.
>>> would also be the port where the RR sends RMS-T, on RS. That is 
>>> mixing the
>> semantics of
>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke
>>>
>>