[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,
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:csp at csperkins.org]
Sent: Thursday, April 30, 2009 2:41 PM
To: Roni Even
Cc: avt at ietf.org
Subject: Re: [AVT] SDP example in
draft-versteeg-avt-rapid-synchronization-for-rtp-03
Roni,
On 29 Apr 2009, at 19:58, Roni Even wrote:
> 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.
That's always been an issue with declarative SDP for multicast
sessions, I'm not sure there's anything special about this SDP.
> 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.
Sure - this gets into NAT traversal issues, of course.
Colin
> 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/
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
--
Colin Perkins
http://csperkins.org/