All things related to multicast

["Richard Mavrogeanes" <>]

Excellent summary, Bill!

Indeed, the source in question is a VBrick. I can't access it, of
course, but I think I can find the owner.  If the SAP is compressed,
then the source is likely MPEG4.

The SDP, especially for MPEG4, became too big (there is a LOT of stuff
required to be fully standards compliant for MPEG4) and we implemented
SDP compression (indeed, as the standards allow). I guess cisco does not
fully follow the standard?

I think we might be able to help out with a SAP decompress/decoder, but
I'm not entirely sure I understand how it would help the problem if the
trouble is in the router?  Is there something we can do to help here?

Rich


-----Original Message-----
From: Bill Owens 
[mailto:]
 
Sent: Friday, March 24, 2006 12:04 PM
To: Richard Mavrogeanes
Cc: 

Subject: Re: Cisco IPv4 Multicast Issue

On Fri, Mar 24, 2006 at 11:24:27AM -0500, Richard Mavrogeanes wrote:
> VBrick has never "intentionally" send non-standard SAP messages, but 
> we do use some the SDP fields in novel ways. I think the question is 
> about the keyword in the SDP, and in 2004 the firmware was changed so 
> that the field was not empty.  Of course, not everyone upgrades, and 
> there are thousands of VBricks out there still running with early 
> versions of the code (some even with 1.0!).

I think there are three separate things crossing each other here:

 - At one point in the past, at least some VBrick SAP messages were
sufficiently different from what the code in sdr and IP/TV expected that
they wouldn't show up in the session list. I was under the impression
that this was intentional because VBrick's stream format couldn't be
decoded by the RTP-based tools, and it was a way to keep users of those
tools from seeing streams they couldn't view. That's what the discussion
was about in 2002, at any rate.

 - Ethereal has a problem with the a=keywds field being empty, which is
what was fixed with the firmware update in 2004 (and didn't appear to
affect any other apps; certainly, the ones I have don't complain)

 - The machine at 129.116.74.139, which may or may not be a VBrick, but
has the reverse name vbrick-cma5136.communication.utexas.edu, is sending
compressed SAP messages. That's triggering the errors on the Cisco
router with 'ip sap listen' enabled, and it can't be decoded by
Ethereal, but it is something that the standard allows. Someone with
some mad Perl or Python skillz could probably decode the packet with
zlib, but I tried that yesterday and couldn't :( 

Bill.