Subject: [AVT] comments on WGLC for RAMS (SSRC in SDP)

From: Roni Even <[email-masked]>
Date: Thu, 14 Jan 2010 17:39:45 +0200

Hi,

I saw Ali's summary and I was wondering about:

"The announcement of media sender SSRCs in the SDPs

This will be optional (but recommended if possible). "

I would like to see the text describing the RTP_Rx behavior including how
does it know that this is the case where each transport address of the FT
uniquely identifies one and only one RTP stream. (Can the multicast server
send other announcements using the same transport addresses on the FT?).

I also think that the text should clarify that the RTP_Rx behaves
differently when receiving the RAMS burst and when receiving a
retransmission stream according to RFC 4588 with regards to the SSRC.

Roni Even

As individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Jan 2010 10:28:16 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Thursday, January 14, 2010 7:40 AM
> To: [email-masked]
> Subject: [AVT] comments on WGLC for RAMS (SSRC in SDP)
> 
> Hi,
> 

Yes, SSRC announcement is a good thing when it is there, the clients should use it. It is the provider's responsibility to make sure that the SSRCs are correct and the FT's are properly assigned. 
 
> 
> 
> I would like to see the text describing the RTP_Rx behavior including how does it know
> that this is the case where each transport address of the FT uniquely identifies one and
> only one RTP stream. (Can the multicast server send other announcements using the same
> transport addresses on the FT?).

It is given a FT address+port. And maybe, it is given an SSRC, too. It does not care whether the FTAp serves a single SSRC or multiple SSRCs. If it is given an SSRC, it uses it. If it does not, it can't obviously put the correct SSRC in the request so it will assume that FTAp serves only a single SSRC.

> I also think that the text should clarify that the RTP_Rx behaves differently when
> receiving the RAMS burst and when receiving a retransmission stream according to RFC 4588
> with regards to the SSRC.

How should it behave differently?

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 14 Jan 2010 21:31:00 +0200

Ali,
If there is more than one RTP session the association between the original
and retransmission stream is done according to section 5.3 of RFC 4588 by
the SSRC. 
In this case it need to be different
Roni Even

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Thursday, January 14, 2010 8:28 PM
> To: Roni Even; [email-masked]
> Subject: RE: [AVT] comments on WGLC for RAMS (SSRC in SDP)
> 
> 
> 
> Yes, SSRC announcement is a good thing when it is there, the clients
> should use it. It is the provider's responsibility to make sure that
> the SSRCs are correct and the FT's are properly assigned.
> 
> >
> >
> It is given a FT address+port. And maybe, it is given an SSRC, too. It
> does not care whether the FTAp serves a single SSRC or multiple SSRCs.
> If it is given an SSRC, it uses it. If it does not, it can't obviously
> put the correct SSRC in the request so it will assume that FTAp serves
> only a single SSRC.
> 
> 
> differently when

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Jan 2010 11:36:03 -0800

There is only *one* retransmission session that does the regular retransmissions and deals with the RAMS. At the end, a burst packet is not any different from a retransmission packet that would be sent as a response to a NACK message.

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, January 14, 2010 11:31 AM
> To: Ali C. Begen (abegen); [email-masked]

---

From: Roni Even <[email-masked]>
Date: Fri, 15 Jan 2010 00:11:19 +0200

Ali,
Maybe I did not ask the question clearly. The RTP_Rx sends two RAMS-R for
two different RTP sessions, now he receives two bursts, how can he know
which one is which.
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, January 14, 2010 9:36 PM
> Subject: Re: [AVT] comments on WGLC for RAMS (SSRC in SDP)
> 
> There is only *one* retransmission session that does the regular
> retransmissions and deals with the RAMS. At the end, a burst packet is
> not any different from a retransmission packet that would be sent as a
> response to a NACK message.
> 
> -acbegen
> 
> > > > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > > Roni Even
> > > > I would like to see the text describing the RTP_Rx behavior
> including
> > > how does it know
> > > > that this is the case where each transport address of the FT
> uniquely
> > > identifies one and
> > > > receiving the RAMS burst and when receiving a retransmission
> stream
> > > according to RFC 4588
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 14 Jan 2010 15:29:28 -0800

If both requests are asking for the same stream, the second one will be an updated request. So, no concerns here.

If two requests are asking for two different streams and the client does not know whether these streams will share the same SSRC or not, it better get them on different ports.

-acbegen

> Sent: Thursday, January 14, 2010 2:11 PM

---

From: Roni Even <[email-masked]>
Date: Sun, 17 Jan 2010 00:55:23 +0200

Ali,
In this case it behave differently since the RTP_Rx must allocate a
different transport address for each RTP stream which is not required by RFC
4588. I am not saying that the solution does not work, I am just suggesting
that there should be some text describing RTP_Rx behavior since most of the
discussion so far was about the server side and not the client side.

Roni Even
As individual.

> Sent: Friday, January 15, 2010 1:29 AM
> If both requests are asking for the same stream, the second one will be
> an updated request. So, no concerns here.
> 
> If two requests are asking for two different streams and the client
> does not know whether these streams will share the same SSRC or not, it
> better get them on different ports.
> 
> -acbegen
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jan 2010 13:43:28 +0100

> discussion so far was about the server side and not the client side.

Roni, If I understand your comment correctly, it comes down to a similar
comment I had about the lack of clarity how different RTP sessions
should be separated and where it is not acceptable to reuse local ports
(RTP sessions) etc.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Mon, 18 Jan 2010 15:18:50 +0200

Yes
Roni

> Sent: Monday, January 18, 2010 2:43 PM
> To: Roni Even
> Cc: [email-masked]