<div>berbee InformaCast</div>
<div> </div>
<div>Rossella--</div>
<div> </div>
<div>Does the Altas speaker have a firmware on it you can get and update?</div>
<div> </div>
<div>Scott<br><br></div>
<div class="gmail_quote">On Mon, Jun 16, 2008 at 9:49 AM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Rossella,<br><br>Good problem. The RFC appears to indicate:<br><a href="http://www.faqs.org/rfcs/rfc2236.html" target="_blank">http://www.faqs.org/rfcs/rfc2236.html</a><br>
"All IGMP messages described in this document are sent with IP<br> TTL 1, and contain the IP Router Alert option [RFC 2113] in their IP<br> header."<br><br>The switch is being a bit aggressive in interpretation, but I'd say the speaker is out of order here. When you say "speaker gets all its configuration parameters from the server". What server do you mean?<br>
<br>Regards,<br><font color="#888888">Wes</font>
<div>
<div></div>
<div class="Wj3C7c"><br><br>Rossella Mariotti-Jones wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello all, I've been approaching this issue from many different sides, so I figured I'd post on this list too. <br>
The players are: an Atlas Sound ip speaker model I128SYS (ceiling), a Foundry switch, and Berbee InformaCast v.5.1.1. <br>The speaker sends multicast membership group report with ttl=16, as soon as it gets to the switch it gets dropped, see the switch message below: <br>
IGMP: Error! ttl=16 (!= 1), discard, pkt S=<a href="http://10.22.3.54/" target="_blank">10.22.3.54</a> to <a href="http://239.0.1.2/" target="_blank">239.0.1.2</a>, on VL221 (phy 0/1/37), igmp_size=8 <br>Foundry says that per RFC 2236, IGMP version 2 Membership Report to the group is sent with IP TTL of 1, so whatever is not equal to 1 gets discarded. <br>
According to Berbee tech support the speaker gets all its configuration parameters from the server however modifying the ttl on the server doesn't change the ttl value that the speaker uses when sending the membership group report, so we think this is a value that's coded in the speaker's firmware. <br>
The speaker works flawlessly on a Cisco switch. We have already put in a feature request with Foundry because we think the problem is how they are enforcing the RFC, in the meantime we are looking for a different kind of ceiling speakers to try on these switches, any suggestions on any of these points? Anybody has or has had something similar happening? <br>
Thanks in advance. <br>***<br>Rossella Mariotti-Jones<br><a href="mailto:rossella@chemeketa.edu" target="_blank">rossella@chemeketa.edu</a><br><br><br>Network Analyst, SS - SPIR - IT TAC<br>
desk 503-589-7775 - cell 503-480-4255<br><br>**** PRIVILEGED AND CONFIDENTIAL COMMUNICATION **** This electronic transmission, and any documents attached hereto, may contain confidential and/or legally privileged information. The information is intended only for use by the recipient named above. If you have received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited.<br>
<br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div></div></blockquote></div><br>