Subject: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03

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

Hi,

I am looking for more feedback on the following topic (not by Roni or Ali).

The example in the draft is coming from a distribution source using for
example SAP (multicast distribution).

There are three entities in the communication. The multicast distribution
source, the unicast retransmission which also serves as a feedback target
and a client that wants to receive the multicast stream and will ask for
unicast  resynchronization or retransmission.

This SDP is coming from the distribution source and according to the authors
specify the multicast address, the unicast transport address for the RTCP
receiver reports for the multicast (SSM), the uincast transport address on
the feedback target/retransmission server that will  be used by the clients
to ask for retransmission streams using RTCP-FB and the transport address on
the client that will be used by the feedback target to send the unicast RTP
stream to.

Does this SDP look like it supplies all this information enabling
interoperable applications.

         v=0

        o=ali 1122334455 1122334466 IN IP4 rams.example.com

        s=Rapid Acquisition Examples

        t=0 0

        a=group:FID 1 2

        a=group:FID 3 4

        a=rtcp-unicast:rsi

        m=video 40000 RTP/AVPF 96

        i=Primary Multicast Stream #1

        c=IN IP4 224.1.1.1/255

        a=source-filter: incl IN IP4 224.1.1.1 192.0.2.2

        a=recvonly

        a=rtpmap:96 MP2T/90000

        a=rtcp:40001 IN IP4 192.0.2.1

        a=rtcp-fb:96 nack

        a=mid:1

        m=video 40002 RTP/AVPF 97

        i=Unicast Retransmission Stream #1 (Ret. Support Only)

        c=IN IP4 192.0.2.1

        a=recvonly

        a=rtpmap:97 rtx/90000

        a=rtcp:40003

        a=fmtp:97 apt=96

        a=fmtp:97 rtx-time=3000

        a=mid:2

Thanks

Roni Even

---

From: Colin Perkins <[email-masked]>
Date: Wed, 29 Apr 2009 17:33:51 +0100

Roni,

It's been a while since I read SDP and its various extensions in great  
detail, but as far as I can tell, this SDP does provide sufficient  
information to join the session, on the assumption that symmetric RTP/ 
RTCP ports can be used.

Colin

On 26 Apr 2009, at 19:48, Roni Even wrote:
> The example in the draft is coming from a distribution source using  
> for example SAP (multicast distribution).
> There are three entities in the communication. The multicast  
> distribution source, the unicast retransmission which also serves as  
> a feedback target and a client that wants to receive the multicast  
> stream and will ask for unicast  resynchronization or retransmission.
>
> This SDP is coming from the distribution source and according to the  
> authors specify the multicast address, the unicast transport address  
> for the RTCP receiver reports for the multicast (SSM), the uincast  
> transport address on the feedback target/retransmission server that  
> will  be used by the clients to ask for retransmission streams using  
> RTCP-FB and the transport address on the client that will be used by  
> the feedback target to send the unicast RTP stream to.
>

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

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Apr 2009 21:58:19 +0300

Colin,
I agree that the assumption is that the client can use this ports but this
is why I suggest that the client should be able to override the offer if it
cannot use these ports. One example is when the client tries to join two
different multicast streams and both offer the same ports.

My other concern is that the client IP address is not known from this SDP,
so there is another assumption that the IP used in the RTCP RAMS=R from the
client is the IP address for the unicast burst.

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 7:34 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [AVT] SDP example in
draft-versteeg-avt-rapid-synchronization-for-rtp-03

Roni,

Colin

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Apr 2009 12:40:42 +0100

Roni,

> different multicast streams and both offer the same ports.

That's always been an issue with declarative SDP for multicast  
sessions, I'm not sure there's anything special about this SDP.

> client is the IP address for the unicast burst.

Sure - this gets into NAT traversal issues, of course.

Colin

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

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

---

From: "Roni Even" <[email-masked]>
Date: Thu, 30 Apr 2009 15:44:41 +0300

Colin,
The special case here is also mentioned in RFC 4566 section 5.7 in the first
bullet in the last sentence.

"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."

Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 2:41 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [AVT] SDP example in

Roni,

Colin

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