[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] SDP example in draft-versteeg-avt-rapid-synchronization-for-rtp-03
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:csp at csperkins.org]
Sent: Wednesday, April 29, 2009 7:34 PM
To: Roni Even
Cc: avt at ietf.org
Subject: Re: [AVT] SDP example in
draft-versteeg-avt-rapid-synchronization-for-rtp-03
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:
> 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
--
Colin Perkins
http://csperkins.org/