[cisco-voip] MOH from Router Flash between internal callers

[Dew Swen]

Yes it's normal.

Conference is like mixed "seperate calls". Your conference region is g711,
and CUCM tells inside phone to start g711 stream. The other calls are like
g729 streams.

http://www.cisco.com/univercd/cc/td/doc/product/access/ip_ph/srs/srsinter/moh.pdf

from http://cciev.wordpress.com :

*C. G711 multicast everywhere, remote site uses MoH from local SRST flash*

1. Create region for MoH. G711 with all other regions.

2. Enable multicast in audio source, server, MRG. Set hop count to 1.

3. Enable only G711 in service parameter (Default)
4. Enable multicast in HQ and Remote LAN infrastructure (igmp snooping in
switches, pim sparse-dense in routers), Disable multicast in WAN
infrastructure.

5. Enable SRST MOH feature from flash.

6. Enable loopback interface in SRST router for PSTN users to hear MoH.


-
Dew Swen


On Wed, Dec 9, 2009 at 11:42 PM, <steve.siltman at assurant.com> wrote:

>
> Thanks for the tips!
>
> I can see that the phone is sending the correct 239.1.1.1 address and port.
>  The internal phones are now hearing the music but the quality is beyond
> bad.   I see on the same page that the sender codec is g.722 and the recr
> codec is g.711u.  Could this be the issue?
>
> Steve Siltman
> Assurant Corporate Technology
> Senior Network Engineer - Cisco CCVP
> Work: 651-361-4752
> Cell: 651-336-5563
> steve.siltman at assurant.com
>
>
>  *Ryan Ratliff <rratliff at cisco.com>*
>
> 2009-12-08 20:11
>   To
> steve.siltman at assurant.com
> cc
> cisco-voip at puck.nether.net
>  Subject
> Re: [cisco-voip] MOH from Router Flash between internal callers
>
>
>
>
> I don't recall this ever not being supported, in fact the whole point of
> using the router flash for MOH was to get it working to phones and PSTN
> gateways at the remote site.
>
> It is most definitely supported and there are quite a few people that use
> it with no issues.  The reason you were asked for traces is because if the
> configuration looks good, then the traces are the best way to confirm what
> MOH audio source/server CUCM is selecting and why the multicast address the
> phone is told to listen to doesn't line up with what the router is sending.
>
> You are correct and it is fairly straight forward.  One slight correction
> is that it is not the phone initiating the hold but rather the CUCM server
> that instructs the held party to listen to the MOH stream.   The address
> used will be a combination of the user hold audio source  configured on the
> holding phone and the MRGL of the held phone.
>
> You can also find out the address the phone is being told to listen to by
> putting the phone on hold, and then pointing a web browser at the held
> phone's IP address.  Click on the Streaming Statistics links until you see
> the multicast address.  If everything is configured correctly then this
> address and port will match that configured on the SRST router.  If it
> doesn't match, then your CUCM configuration is not correct.  If it does
> match and the phone is still hearing silence on hold then you need to
> troubleshoot the layer 2 and 3 multicast between the SRST router and the IP
> phone.
>
> -Ryan
>
> On Dec 8, 2009, at 4:22 PM, *steve.siltman at assurant.com*<steve.siltman at assurant.com>wrote:
>
>
> Has anyone been able to get this too work?  I turned on Multicast within
> the internal network at this remote site and I'm unable to get the phones to
> hear the MOH between two internal Cisco IP Phones.  Years ago, I read that
> this wasn't possible but was hoping this was resolved in later versions.  We
> are running v7 Call Manager with 12.4.24 router code.  MOH works fine to
> external customers.  It seems fairly straight forward as the one Cisco IP
> phone issues the Hold and sends the multicast ip address to the other phone.
>  I'm not sure why the other phone doesn't pick up on the stream.  Grr
>
> If this isn't supported then I'll have to allow MOH across the WAN and
> forget about using the routers flash outside of SRST.
>
> I've got a ticket open with Cisco and they verified the configuration and
> have asked for trace files.  Either this TAC person doesn't know it isn't
> supported or something has changed since my Cisco Voice Gateways book was
> printed in 2006.
>
> Thanks,
>
> -Steve
> This e-mail message and all attachments transmitted with it may contain
> legally privileged and/or confidential information intended solely for the
> use of the addressee(s). If the reader of this message is not the intended
> recipient, you are hereby notified that any reading, dissemination,
> distribution, copying, forwarding or other use of this message or its
> attachments is strictly prohibited. If you have received this message in
> error, please notify the sender immediately and delete this message and all
> copies and backups thereof. Thank
> you._______________________________________________
> cisco-voip mailing list*
> **cisco-voip at puck.nether.net* <cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> This e-mail message and all attachments transmitted with it may contain
> legally privileged and/or confidential information intended solely for the
> use of the addressee(s). If the reader of this message is not the intended
> recipient, you are hereby notified that any reading, dissemination,
> distribution, copying, forwarding or other use of this message or its
> attachments is strictly prohibited. If you have received this message in
> error, please notify the sender immediately and delete this message and all
> copies and backups thereof. Thank you.
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091210/ceb5b287/attachment.html>