Hi Vik, My response/querry in between lines to your response please...I hv have Q's???
--- On Wed, 1/14/09, Vik Malhi <vma...@ipexpert.com> wrote: From: Vik Malhi <vma...@ipexpert.com> Subject: Re: [OSL | CCIE_Voice] MOH Issue To: "Alex" <alex.arsen...@gmail.com> Cc: ccie_voice@onlinestudylist.com Date: Wednesday, January 14, 2009, 11:18 PM The two solutions work- either you place your MOH server in a g711-always DP and your should set the SRST router to use 239.1.1.1 >>>.with this I beleive we will only have G711 MOH stream only ??? Are we supposed to set on SRST router to use 239.1.1.3....then the stream will be G729 or still G711 ???? And what should be set on IPVMA Service Parameter just G711 or both OR...IF you did but the MOH server in a DP that uses g729 to site B (for whatever reason) then you should set the SRST router to use 239.1.1.3. ---with this tte strea mwill be G729 ...???? And what should be set on IPVMA Service Parameter just G711 or both The MOH file on the flash will be sent out using the same IP Address CCM is telling the phone/gateway to listen. The phone on hold is receiving RTP packets and the payload type will be g711u- however CCM “thinks” that the MOH server back in HQ is active and the stream is g729. But I guess that’s the whole idea of spoofing- CCM is not aware of what is going on. The codec CCM “thinks” is being used and the actual codec are different- but that will not affect the end result. Also- while we are on the topic of sourcing music from the flash- you all should be putting in the command: no mgcp timer receive-rtcp (in the case of an MGCP gateway).... -- Vik Malhi – CCIE #13890, CCSI #31584 Senior Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: vma...@ipexpert.com Join our free online support and peer group communities: http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: Alex <alex.arsen...@gmail.com> Date: Wed, 14 Jan 2009 13:58:36 -0000 To: Vik Malhi <vma...@ipexpert.com> Cc: <ccie_voice@onlinestudylist.com> Subject: Re: [OSL | CCIE_Voice] MOH Issue Vik, AFAIK if G.729 is enabled in IPVMSA and MOH server is in HQ DP (which allows only G.729 to Site B) then the following happens: - CCM instructs Site B phones to join mcast group 239.1.1.3 which is G.729 MOH -Site B router streams only G.711 MOH from flash to 239.1.1.1 http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d1c31.html#wp1043334 Expected result: no MOH on Site B phones If G.729 is not enabled for IPVMSA and MOH server is in HQ DP (which allows only G.729 to Site B), then: - CCM cannot find a suitable mcast group for Site B phones to join Expected result: no MOH on Site B phones If G.729 is not enabled for IPVMSA and MOH server is in G.711-only DP (which allows G.711 to Site B), then: - CCM instructs Site B phones to join mcast group 239.1.1.1 which is G.711 ulaw MOH -Site B router streams only G.711 MOH from flash to 239.1.1.1 Expected result: MOH plays on Site B phones Do I miss something here? Rgds Alex ----- Original Message ----- From: Vik Malhi <mailto:vma...@ipexpert.com> To: kamal yousaf <mailto:lovingprin...@gmail.com> ; Christian Hennrich <mailto:christian.hennr...@intact-is.com> Cc: ccie_voice@onlinestudylist.com ; Kumar,Narinder <mailto:narinder.ku...@uxcg.com.au> Sent: Wednesday, January 14, 2009 6:39 AM Subject: Re: [OSL | CCIE_Voice] MOH Issue 239.1.1.1 port 16384 is always reserved for g711u for Audio Source 1, 239.1.1.2 for g711alaw, 239.1.1.3 for g729 and 239.1.1.4 for Wideband. Since the BR1 DP is communicating with the MOH server using g729 (or should I say CCM “thinks” g729 is the negotiated codec whereas in realty we are spoofing from the remote site router) CallManager will increment on port # or ip address. In your case MOH<--->BR1 DP uses g729 and you increment on ip address. You should have G729 allowed in IP Voice Media Streaming App for this to work. Everything on CallManager should be configured as normal- without enabling g729 will cause the MOH sourced from the flash to fail. You need the commands as shown below. Call-manager-fallback Moh filename ( Moh file in flash no multicast moh 239.1.1.1 port 16384 route x.x.x.x multicast moh 239.1.1.3 port 16384 route x.x.x.x Note – you cannot change multicast ip addresses on the fly and so you must delete the first command (incorrect multicast cmd). -- Vik Malhi – CCIE #13890, CCSI #31584 Senior Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: vma...@ipexpert.com Join our free online support and peer group communities: http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: kamal yousaf <lovingprin...@gmail.com> Date: Wed, 14 Jan 2009 16:13:35 +1100 To: Christian Hennrich <christian.hennr...@intact-is.com> Cc: <ccie_voice@onlinestudylist.com>, "Kumar, Narinder" <narinder.ku...@uxcg.com.au> Subject: Re: [OSL | CCIE_Voice] MOH Issue Alex, Regarding your comment, If MOH server uses 239.1.1.3 to stream G729 to remote phones, shouldn't we enable G.729 for MOH ? Only exception is using transcoder but since it can't be used for multicast,don't we have to enable G.729 ? Alex schrieb: Your mcast group IP@ in below debug is 239.1.1.3 The same group IP@ should be configured on SiteB router. No need to enable G.729 for MoH - if you ticked "increment on IP address" that's probably why the group IP@ got changed. Rgds Alex *From:* Kumar, Narinder <mailto:narinder.ku...@uxcg.com.au> *To:* ccie_vo...@onlinestudylist.com <mailto:ccie_voice@onlinestudylist.com> *Sent:* Tuesday, January 13, 2009 12:36 PM *Subject:* [OSL | CCIE_Voice] MOH Issue Quick Que on MOH CCM running multicast MOH. Between Site A and Site B only g729 allowed SiteA will receive multicast MOH . Site B will receive multicast MOH from router flash, no multicast traffic allowed between Ste A and SiteB. The way I do this question is Configure the MOH source file and tick multicast and play continuously Enable multicast on the MRG and MOH server Change the ip voice media service parameter to allow both g711 and g729 Site A works without any issue Site B Configuration: Call-manager-fallback Moh filename ( Moh file in flash) multicast moh 239.1.1.1 port 16384 route x.x.x.x MOH from site B doesn't work , what am I missing here ? *************************************** debug ccm-manager music-on-hold all ************************************** an 13 13:13:30.023: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:30.023: moh_process_ccb: dstadr 0.0.0.0, callid 18, port 0, codec 65535, moh_en 0, moh_addr 0.0.0.0 *Jan 13 13:13:30.023: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:30.079: moh_process_ccb: dstadr 142.102.65.6, callid 18, port 23552, codec 5, moh_en 0, moh_addr 0.0.0.0 *Jan 13 13:13:30.079: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:31.391: %ISDN-6-CONNECT: Interface Serial0/1/0:2 is now connected to 911 N/A *Jan 13 13:13:31.395: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:31.395: moh_process_ccb: dstadr 142.102.65.6, callid 18, port 23552, codec 5, moh_en 0, moh_addr 0.0.0.0 *Jan 13 13:13:31.399: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:33.103: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:33.103: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:33.103: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:33.119: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:33.139: moh_process_ccb: dstadr 239.1.1.3, callid 18, port 16384, codec 16, moh_en 0, moh_addr 0.0.0.0 *Jan 13 13:13:33.139: moh_process_ccb:multicast addr add_ccb *Jan 13 13:13:33.139: moh_add_ccb: ip addr 239.1.1.3 port 16384 callid 18 *Jan 13 13:13:33.139: moh_add_ccb: vmccb does not exists - creating a new one for 239.1.1.3 through IGMP *Jan 13 13:13:33.139: moh_join_group_command called for 239.1.1.3 *Jan 13 13:13:33.139: moh_join_group_command: Looking at valid idb's to configure 239.1.1.3 *Jan 13 13:13:33.139: moh_join_group_command: IGMP API on group 239.1.1.3 idb Se0/0/0.201 *Jan 13 13:13:33.139: moh_join_group_command: IGMP API on group 239.1.1.3 idb Vl102 *Jan 13 13:13:33.139: moh_create_session: called *Jan 13 13:13:33.139: moh_create_session : dstadr 239.1.1.3 does not exist - creating a control block *Jan 13 13:13:33.139: moh_insert_multicast_hashtable:moh_insert_multicast_hashtable buc 2 *Jan 13 13:13:33.139: moh_create_session : Created a new vmccb for 239.1.1.3 *Jan 13 13:13:33.139: moh_send_join: Looking at valid idb's to configure 239.1.1.3 *Jan 13 13:13:33.139: moh_add_ccb: Done inserting CCB for 239.1.1.3 *Jan 13 13:13:33.139: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:36.091: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:36.091: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:36.091: update_stream_info: stream_flag Reset *Jan 13 13:13:36.091: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:36.091: update_stream_info: stream_flag Reset *Jan 13 13:13:36.115: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:36.115: update_stream_info: stream_flag Reset *Jan 13 13:13:36.183: moh_process_ccb: dstadr 142.102.65.6, callid 18, port 24164, codec 5, moh_en 1, moh_addr 239.1.1.3 *Jan 13 13:13:36.183: moh_process_ccb:multicast addr delete_ccb call id 18 moh_call_id 18 *Jan 13 13:13:36.183: moh_delete_ccb: called dstadr 239.1.1.3, callid 18 *Jan 13 13:13:36.183: moh_delete_ccb_ext:called dstadr 239.1.1.3, callid 18 *Jan 13 13:13:36.183: moh_delete_ccb_ext:ipaddr 239.1.1.3 callid 18 *Jan 13 13:13:36.183: moh_delete_ccb_ext : Deleted the ccb entry *Jan 13 13:13:36.183: moh_leave_group_command called for 239.1.1.3 *Jan 13 13:13:36.183: moh_remove_group: called for 239.1.1.3 *Jan 13 13:13:36.183: moh_remove_group Leaving 239.1.1.3 *Jan 13 13:13:36.187: moh_remove_group Leaving 239.1.1.3 *Jan 13 13:13:36.195: moh_delete_session : Freed up vmccb for 239.1.1.3 *Jan 13 13:13:36.195: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:37.427: moh_update_rtp: callID 17 dstCallID 18 *Jan 13 13:13:37.439: moh_update_rtp: callID 17 dstCallID 18 Thanks Narinder ------------------------------------------------------------------------ CONFIDENTIALITY - The information contained in this electronic mail message is confidential and is intended solely for the addressee(s). If you are not an authorised recipient of this message please contact Getronics Australia immediately by reply email and destroy/delete this message from your computer. Any unauthorised form of reproduction of this message, or part thereof, is strictly prohibited. DISCLAIMER - Unless specifically indicated otherwise, the views and opinions expressed in this email are those of the sender and not Getronics Australia. While we endeavour to protect our network from computer viruses, Getronics Australia does not warrant that this email or any attachments are free of viruses or any other defects or errors. It is the duty of the recipient to virus scan and otherwise test any information contained in this email before loading onto any computer system. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
