[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

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/