Subject: [AVT] Comment on RAMS related to SDP

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 1 Mar 2010 15:52:20 +0100

Ali, and other SDP experts...
 
I got a remark that it does not make sense to include a declarative SDP
for the Retransmission Server in the AVT WG RAMS draft, which contains
the attributes and transport addresses for the RTP unicast session
carrying the burst and retransmissions and the RTCP feedback channel
associated with a source specific multicast. These addresses/ports
cannot be imposed upon a Retransmission Server (acting as the feedback
Target and the source of the unicast RTP session). 
 
So, we should remove this SDP... What are other people's opinions?
 
Tom

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 1 Mar 2010 06:58:54 -0800

Yes, I remember the same comment from an earlier email. However, I am
not sure what needs to be changed. I am hoping that any incorrect SDP
description will be caught in the wglc process.

Section 8 is the relevant section. Will be good of mmusic can comment on
it.
http://tools.ietf.org/html/draft-ietf-avt-rapid-acquisition-for-rtp-07 

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
VAN CAENEGEM Tom
> Sent: Monday, March 01, 2010 9:52 AM
> To: [email-masked]; [email-masked]
> Subject: [AVT] Comment on RAMS related to SDP
> 
> I got a remark that it does not make sense to include a declarative
SDP for the Retransmission Server
> in the AVT WG RAMS draft, which contains the attributes and transport
addresses for the RTP unicast
> session carrying the burst and retransmissions and the RTCP feedback
channel associated with a source
> specific multicast. These addresses/ports  cannot be imposed upon a
Retransmission Server (acting as
> the feedback Target and the source of the unicast RTP session).
>

---

From: "Jose Rey" <[email-masked]>
Date: Mon, 1 Mar 2010 17:40:13 +0100

Ali,

I don't understand what the SDP in page 40 Figure 10 is used for. Caption says "Figure 10: Example SDP for RTP_Rx when RAMS support is enabled " So who sends it and to whom ? 

More inline...

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
> Sent: Monday, March 01, 2010 3:59 PM
> To: VAN CAENEGEM Tom; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] [AVT] Comment on RAMS related to SDP
> 

Actually I think Figure 9 would be something the client could retrieve to know about the session, and it makes sense to me. However, it would be helpful to be more verbose on the semantics of, e.g., a=rtcp, <port>,... in each multicast and unicast m= lines. That is something which hasn't been specified before, it's new. 

> > So, we should remove this SDP... What are other people's opinions?

Figure 10, yes.

Cheers,

José

> > Tom
> > 
> > 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 

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: Mon, 1 Mar 2010 10:39:46 -0800

> From: Jose Rey [mailto:[email-masked]]
> Sent: Monday, March 01, 2010 11:40 AM
> To: Ali C. Begen (abegen); VAN CAENEGEM Tom; [email-masked]; [email-masked]
> Subject: RE: [MMUSIC] [AVT] Comment on RAMS related to SDP
> 
> Ali,
> 
> I don't understand what the SDP in page 40 Figure 10 is used for. Caption says "Figure 10: Example SDP
> for RTP_Rx when RAMS support is enabled " So who sends it and to whom ?

This is sdp description the client (RTP_Rx) gets. The difference from figure 9 (which is the sdp for the server) is the a=recvonly vs a=sendonly for the unicast stream (which is actually obvious in an SSM context but we kept it to be more explicit).

These SDPs could be sent by a management server that oversees the SSM sessions.
 
> Actually I think Figure 9 would be something the client could retrieve to know about the session, and
> it makes sense to me. However, it would be helpful to be more verbose on the semantics of, e.g.,
> a=rtcp, <port>,... in each multicast and unicast m= lines. That is something which hasn't been
> specified before, it's new.

Why do you say figure 9? And what else needs to be more verbose? There is a lot of explanation in the SDP section saying what line stands for what. If you have specific comments, please let us know.
 
> > > So, we should remove this SDP... What are other people's opinions?

If we remove figure 10, that a=sendonly/recvonly lines need to go away. But, I am not positive that is the only reason you wanna remove that sdp from the draft.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2010 20:50:18 +0100

VAN CAENEGEM Tom skrev 2010-03-01 15:52:
> for the Retransmission Server in the AVT WG RAMS draft, which
> contains the attributes and transport addresses for the RTP unicast
> channel associated with a source specific multicast. These
> addresses/ports  cannot be imposed upon a Retransmission Server (acting
> as the feedback Target and the source of the unicast RTP session).
>  

I think you can remove that. Or At least you should separate the
configuration of the RTP_RX and the RS clearly. This as the RTP_RX
configuration requires that one has decided details on the RS combined
with the media source and multicast group.

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: "Jose Rey" <[email-masked]>
Date: Tue, 2 Mar 2010 14:10:00 +0100

Ali,

Inline...
> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Monday, March 01, 2010 7:40 PM
> To: Jose Rey; VAN CAENEGEM Tom; [email-masked]; [email-masked]
> > I don't understand what the SDP in page 40 Figure 10 is 
> used for. Caption says "Figure 10: Example SDP
> This is sdp description the client (RTP_Rx) gets. The 
> difference from figure 9 (which is the sdp for the server) is 
> the a=recvonly vs a=sendonly for the unicast stream (which is 
> actually obvious in an SSM context but we kept it to be more 
> explicit).
> 

Being explicit is desireable IMO, so that's okay. 

>From RFC 3264:

"  If the offerer wishes to only send media on a stream to its peer, it
   MUST mark the stream as sendonly with the "a=sendonly" attribute.  We
   refer to a stream as being marked with a certain direction if a
   direction attribute was present as either a media stream attribute or....
" 
According to the above, if the receiver retrieves an SDP that has a=recvonly for the unicast retransmissions/burst stream:
        
        i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=recvonly
        ...

 then this SDP tells it that it has to send the retransmissions itself. 
 
> > Actually I think Figure 9 would be something the client 
> could retrieve to know about the session, and
> Why do you say figure 9? 

If Figure 10 shall describe the SDP the client shall retrieve from RS or SSM coordinator to understand what's going on, then I think the unicast shall be set to 'sendonly' (similar comments apply to the a=recvonly in the mcast line). Am I missing something?

Cheers,
José

> And what else needs to be more 
> verbose? There is a lot of explanation in the SDP section 
> saying what line stands for what. If you have specific 
> comments, please let us know.
>  
> If we remove figure 10, that a=sendonly/recvonly lines need 
> to go away. But, I am not positive that is the only reason 
> you wanna remove that sdp from the draft.
> 
> -acbegen
>  
> > Cheers,
> > 
> > José
> > 
> > > > Tom
> > > >
> > > >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 2 Mar 2010 10:50:13 -0800

> According to the above, if the receiver retrieves an SDP that has
a=recvonly for the unicast
> retransmissions/burst stream:
> 

I was not reading it that way. If the client receives an SDP with
a=recvonly, it means it is supposed to receive data not send it. But, I
am by no means an sdp guy. 

I suggest we can safely remove those lines and one of the SDPs from the
draft. In RAMS context, it is clear who sends data and who receives data
in the unicast session. No need for confusion.

-acbegen

---

From: "Jose Rey" <[email-masked]>
Date: Wed, 3 Mar 2010 10:12:29 +0100

Ali,

[...]
> in the unicast session. .
We just have to get the directionality right. If node A just sends, then we write down what A does: sendonly. It's that simple. If nothing is written, the communication is bidirectional per default, that is just how it is defined so that a client doesn't have to 'think' in which scenario it is - just read out the attributes. Removing the recvonly from the mcast line and putting a sendonly in the SDP a client gets would do.

> No need for confusion
This is certainly only a nit, but I think it is important to get the SDP right. 

Cheers,
José