Apple Event: May 7th at 7 am PT

> Learn more

> Add to your calendar 

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: OswaldSudden
OswaldSudden Author
User level: Level 1
0 points

Stop or Redirect RTCP Multicast via SDP Files (Help!)

I've got a piece of hardware (Optibase MM400 encoder) that generates both an SDP file and a multicast RTP video stream. (I've configured it to omit the audio stream.) The SDP looks like this:

(Note: I've obscured some of the IPs with letters) 

v=0 o=INGESTSERVERA7 723 75540417 IN IP4 AAA.BBB.239.243 s=MM-400 t=0 0 a=x-authentication:A989B14958B5089A940C1201 a=isma-compliance:1,1,1 a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoILAE8BAQABAQOBJgABQIhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVWtCUndVZkEwTUE0QVFFT3lBUkFGQUFBQURhd0FBQTJzQUZMQUFBQWJBQkFBQUJzbFZWQUFBQnRRa0FBQUVCQUFBQklRQ080QUFnSXlBQWFBQkNnRWdBOVFXRURoUmpCZ0VEBA0BBQAAyAAAAAAAAAAABgkBAAAAAAAAAAADWQACQDZkYXRhOmFwcGxpY2F0aW9uL21wZWc0LWJpZnMtYXU7YmFzZTY0LHdCQVNZUVNJVUVVRlB3QT0EEgINAAAUAAAAAAAAAAAFAwAAQAYJAQAAAAAAAAAA" m=video 11110 RTP/AVP 96 c=IN IP4 239.1.7.193/127 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=1; config=000001B001000001B25555000001B5090000010100000121008EE00020232000680042804800F505840E1463 a=mpeg4-esid:224


The problem is that both VLC and QuickTime spit out multicast packets in response to the streaming video--e.g. RTCP. (I'll explain why this is a problem in a followup message.)

I tried using the RTCP bandwidth specifiers (b=RR: and b=RS:) in both the session and media contexts, but it they didn't affect the RTCP packet rate (one every five seconds).

Here's how I used them in the session context: 

v=0 o=INGESTSERVERA7 723 75540417 IN IP4 AAA.BBB.239.243 s=MM-400 b=RR:0 b=RS:0 t=0 0 a=x-authentication:A989B14958B5089A940C1201 a=isma-compliance:1,1,1 a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoILAE8BAQABAQOBJgABQIhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVWtCUndVZkEwTUE0QVFFT3lBUkFGQUFBQURhd0FBQTJzQUZMQUFBQWJBQkFBQUJzbFZWQUFBQnRRa0FBQUVCQUFBQklRQ080QUFnSXlBQWFBQkNnRWdBOVFXRURoUmpCZ0VEBA0BBQAAyAAAAAAAAAAABgkBAAAAAAAAAAADWQACQDZkYXRhOmFwcGxpY2F0aW9uL21wZWc0LWJpZnMtYXU7YmFzZTY0LHdCQVNZUVNJVUVVRlB3QT0EEgINAAAUAAAAAAAAAAAFAwAAQAYJAQAAAAAAAAAA"


Here's how I used them in the media context: 

m=video 11110 RTP/AVP 96 c=IN IP4 239.1.7.193/127 b=RR:0 b=RS:0 a=rtpmap:96 MP4V-ES/90000 a=fmtp:96 profile-level-id=1; config=000001B001000001B25555000001B5090000010100000121008EE00020232000680042804800F505840E1463 a=mpeg4-esid:224


I also tried it once with the "b=AS:" value set to the total size of the media stream.

Next, I tried to use the "a=rtcp:" attribute to redirect the packets to a different IP (unicast) and then just a different port.

Here's how I used it in the session context: 

v=0 o=INGESTSERVERA7 723 75540417 IN IP4 AAA.BBB.239.243 s=MM-400 t=0 0 a=rtcp:11223 IN IP4 10.10.10.10 a=x-authentication:A989B14958B5089A940C1201 a=isma-compliance:1,1,1 a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoILAE8BAQABAQOBJgABQIhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVWtCUndVZkEwTUE0QVFFT3lBUkFGQUFBQURhd0FBQTJzQUZMQUFBQWJBQkFBQUJzbFZWQUFBQnRRa0FBQUVCQUFBQklRQ080QUFnSXlBQWFBQkNnRWdBOVFXRURoUmpCZ0VEBA0BBQAAyAAAAAAAAAAABgkBAAAAAAAAAAADWQACQDZkYXRhOmFwcGxpY2F0aW9uL21wZWc0LWJpZnMtYXU7YmFzZTY0LHdCQVNZUVNJVUVVRlB3QT0EEgINAAAUAAAAAAAAAAAFAwAAQAYJAQAAAAAAAAAA"


...then just thet port... 

a=rtcp:11223


This didn't affect the RTCP packets from VLC or QuickTime one bit, while changing the media port did have an effect--proving that the SDP files were being read.

On last thing I tried was the "a=rtcp:unicast reflection" attribute, hoping it would return traffic to a unicast address that I could blackhole.

Here's how I used it: 

v=0 o=INGESTSERVERA7 723 75540417 IN IP4 AAA.BBB.239.243 s=MM-400 t=0 0 a=rtcp:a=rtcp:unicast reflection a=rtcp:11223 IN IP4 10.10.10.10 a=x-authentication:A989B14958B5089A940C1201 a=isma-compliance:1,1,1 a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoILAE8BAQABAQOBJgABQIhkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVWtCUndVZkEwTUE0QVFFT3lBUkFGQUFBQURhd0FBQTJzQUZMQUFBQWJBQkFBQUJzbFZWQUFBQnRRa0FBQUVCQUFBQklRQ080QUFnSXlBQWFBQkNnRWdBOVFXRURoUmpCZ0VEBA0BBQAAyAAAAAAAAAAABgkBAAAAAAAAAAADWQACQDZkYXRhOmFwcGxpY2F0aW9uL21wZWc0LWJpZnMtYXU7YmFzZTY0LHdCQVNZUVNJVUVVRlB3QT0EEgINAAAUAAAAAAAAAAAFAwAAQAYJAQAAAAAAAAAA"


...and still, the VLC/QuickTime Player clients continued to spit out RTCP multicast traffic on the port (11111) following the media port (11110).

Anyone have any ideas what I'm doing wrong? Surely VLC and/or QuickTime has implemented a solution.

Note, this problem was identified in the QuickTime forums a few times, but never addressed:
* http://discussions.apple.com/thread.jspa?messageID=8020690&#8020690
* http://discussions.apple.com/thread.jspa?messageID=2543521&#2543521
* http://lists.apple.com/archives/streaming-server-dev/2003/Jul/msg00037.html

One last note: I successfully delivered the SDP file as a local file, a web file, and wrapped within a SAP multicast.. all with the same results.

N/A, Windows XP Pro, N/A

Posted on Dec 16, 2008 10:27 PM

Reply
3 replies
User profile for user: OswaldSudden
OswaldSudden Author
User level: Level 1
0 points

Dec 16, 2008 10:28 PM in response to OswaldSudden

For the purposes of completeness, and evidence that I've been digging for the answer, here's some overview and reference information.

Intro (skip if you know about RTCP and its downsides)

For people just running into this problem. VLC and QuickTime Player send out a multicast packet every 5 seconds in response to multicast RTP stream(s) identified via SDP files. These packets are "RTCP", which is sent by RTP clients to report on the quality of the streams from the client perspective.

The problem is, these packets can overwhelm a system with thousands of clients:
* All client packets have to be delivered to all other clients (huge complexity)
* Routers have to maintain giant lists of the multicast senders
* Many systems are only efficient for single-source multicast traffic (think satellites)

Note: As I understand it, the RTCP multicast packets are sent to all clients so that each client can throttle the overall RTCP bandwidth to reasonable levels. While this is clever solution, it doesn't reduce the number of multicast senders--just the frequency of their packets.

Possible Solutions

I've read through a lot of the SDP/RTP specs. It seems like the preferred (by the spec authors) solution is to redirect the RTCP traffic to a unicast location and then rebroadcast the RTCP traffic from the same single source.

This spec mentions the "rtcp-unicast" option:

Draft Spec: RTCP with Unicast Feedback ( http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-17)

This spec specifies means of directing RTCP traffic to specific ports/IPs (presumably unicast included):

RFC 3605: RTCP attribute in SDP ( http://www.packetizer.com/rfc/rfc3605/)

Another potential solution (ideal in my case), is to pinch the bandwidth for RTCP traffic down to zero, effectively stopping all RTCP traffic from the clients.

This spec specifies the "b=AS:", "b=RS:", and "b=RR:" bandwidth modifiers:

RFC 3556: Session Description Protocol (SDP) Bandwidth Modifier ( http://www.faqs.org/rfcs/rfc3556.html)

Other Specs

RFC 4566: SDP: Session Description Protocol ( http://www.ietf.org/rfc/rfc4566)
* Replaced RFC 2327: SDP: Session Description Protocol ( http://www.ietf.org/rfc/rfc4566)
RFC 3550: RTP: A Transport Protocol for Real-Time Applications ( http://www.ietf.org/rfc/rfc3550.txt)
* Replaced RFC 1889: RTP: A Transport Protocol for Real-Time Applications ( http://www.rfc-editor.org/rfc/rfc1889.txt)

RFC 3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)
RFC 4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
RFC 1890: RTP Profile for Audio and Video Conferences with Minimal Control

Question: Which RFC(s) is QuickTime compliant with?
Reply
User profile for user: OswaldSudden
OswaldSudden Author
User level: Level 1
0 points

Mar 16, 2009 3:59 PM in response to OswaldSudden

Quicktime

We managed to stop Quicktime from generating RTCP packets by setting the TTL (time to live)
of the video stream to 0 within the SDP file.

So for this example SDP file (auto-generated by the Optibase encoding hardware):

v=0
o=INGESTSERVERA7 723 75540417 IN IP4 AAA.BBB.239.243
s=MM-400
t=0 0
a=x-authentication:A989B14958B5089A940C1201
a=isma-compliance:1,1,1
a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoILAE8BAQABAQOBJgABQIhkYXRhOmFwcGxpY2F0aW9u L21wZWc0LW9kLWF1O2Jhc2U2NCxBVWtCUndVZkEwTUE0QVFFT3lBUkFGQUFBQURhd0FBQTJzQUZMQUFB QWJBQkFBQUJzbFZWQUFBQnRRa0FBQUVCQUFBQklRQ080QUFnSXlBQWFBQkNnRWdBOVFXRURoUmpCZ0VE BA0BBQAAyAAAAAAAAAAABgkBAAAAAAAAAAADWQACQDZkYXRhOmFwcGxpY2F0aW9uL21wZWc0LWJpZnMt YXU7YmFzZTY0LHdCQVNZUVNJVUVVRlB3QT0EEgINAAAUAAAAAAAAAAAFAwAAQAYJAQAAAAAAAAAA"
m=video 11110 RTP/AVP 96
c=IN IP4 239.1.7.193/127
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=1; config=000001B001000001B25555000001B5090000010100000121008EE0002023200068004280 4800F505840E1463
a=mpeg4-esid:224

...we change the "c=" line to:

c=IN IP4 239.1.7.193/0

This is effectively telling Quicktime that the source video is being broadcast
with a TTL of 0 (which is a lie). Fortunately, Quicktime sends RTCP packets with
the same TTL as specified for the source video in the SDP.
For TTL=0, it doesn't even generate the packets.

VLC

We have not figured out a solution for VLC. We did get our hands on a Cisco
IPTV unit (the system we're replacing with the Optibase encoding solution). After some trial and error, we've
concluded that there is no resolution for VLC versus Cisco IPTV either.
Cisco IPTV's primary solution is to provide a custom viewer (as opposed to VLC or Quicktime)
and then embed custom fields within the SDP that can control RTCP traffic.
Reply
User profile for user: OswaldSudden
OswaldSudden Author
User level: Level 1
0 points

Mar 16, 2009 4:00 PM in response to OswaldSudden

Quicktime

We managed to stop Quicktime from generating RTCP packets by setting the TTL (time to live)
of the video stream to 0 within the SDP file.

So for this example SDP file (auto-generated by the Optibase encoding hardware):

v=0
o=INGESTSERVERA7 723 75540417 IN IP4 AAA.BBB.239.243
s=MM-400
t=0 0
a=x-authentication:A989B14958B5089A940C1201
a=isma-compliance:1,1,1
a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoILAE8BAQABAQOBJgABQIhkYXRhOmFwcGxpY2F0aW9u L21wZWc0LW9kLWF1O2Jhc2U2NCxBVWtCUndVZkEwTUE0QVFFT3lBUkFGQUFBQURhd0FBQTJzQUZMQUFB QWJBQkFBQUJzbFZWQUFBQnRRa0FBQUVCQUFBQklRQ080QUFnSXlBQWFBQkNnRWdBOVFXRURoUmpCZ0VE BA0BBQAAyAAAAAAAAAAABgkBAAAAAAAAAAADWQACQDZkYXRhOmFwcGxpY2F0aW9uL21wZWc0LWJpZnMt YXU7YmFzZTY0LHdCQVNZUVNJVUVVRlB3QT0EEgINAAAUAAAAAAAAAAAFAwAAQAYJAQAAAAAAAAAA"
m=video 11110 RTP/AVP 96
c=IN IP4 239.1.7.193/127
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=1; config=000001B001000001B25555000001B5090000010100000121008EE0002023200068004280 4800F505840E1463
a=mpeg4-esid:224

...we change the "c=" line to:

c=IN IP4 239.1.7.193/0

This is effectively telling Quicktime that the source video is being broadcast
with a TTL of 0 (which is a lie). Fortunately, Quicktime sends RTCP packets with
the same TTL as specified for the source video in the SDP.
For TTL=0, it doesn't even generate the packets.

VLC

We have not figured out a solution for VLC. We did get our hands on a Cisco
IPTV unit (the system we're replacing with the Optibase encoding solution). After some trial and error, we've
concluded that there is no resolution for VLC versus Cisco IPTV either.
Cisco IPTV's primary solution is to provide a custom viewer (as opposed to VLC or Quicktime)
and then embed custom fields within the SDP that can control RTCP traffic.
Reply

Stop or Redirect RTCP Multicast via SDP Files (Help!)

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.
Learn more Sign up