Re: [OSL | CCIE_Voice] MOH issue
Also: ccm-manager music-on-hold configured on br1? On 29 Feb 2012, at 13:02, Brian Valentine wrote: > Sorry... read too fast. I see it there on the subinterfaces now. Are you > testing via set to set or via pstn? Pstn should need a loopback ro work. > > On Feb 29, 2012 6:59 AM, "Brian Valentine" wrote: > Yes. You arent making pim neighbor relationships over the wan link. > > Enable pim on your wan interfaces. > > On Feb 29, 2012 6:44 AM, "Ashwani" wrote: > Juan, > > Yes igmp-snooping is disabled on switches. I forgot to paste my switch > configuration. Also I have Trans-coder setup for CorpHQ and BR1 site. Also > CUCM MoH is setup for G711 only and Region for CorpHQ and BR1 is allowed > G729. Thanks for looking into this issue. > > Ashwani > > On 2/29/2012 12:14 AM, Juan Lopez wrote: >> >> Ashwani, >> have you turned off 'ip igmp snooping' on the switch? The silence indicates >> a network issue, not a ucm/resource issue. Also note, no mmoh over IPSec >> tunnels. >> >> On 29 Feb 2012, at 05:27, Ashwani wrote: >> >>> Hello Experts, >>> >>> I am trying to do MoH lab but I am not seeing the result as expected. Here >>> is my scenario, relevant configuration and my test results >>> >>> MOH Audio Stream Number >>> >>> MOH Audio Source File >>> >>> Play Continuously >>> >>> Allow Multicasting >>> >>> 1 >>> >>> Source 1 >>> >>> Check >>> >>> Not Check >>> >>> 2 >>> >>> Source 2 >>> >>> Check >>> >>> Check >>> >>> 3 >>> >>> Source 3 >>> >>> Check >>> >>> Not Check >>> >>> >>> >>> MOH Server Name >>> >>> Device Pool >>> >>> Enable Multicast >>> >>> Selected Multicast Audio Sources >>> >>> Max Hops >>> >>> MOH_PUB >>> >>> DP_CorpHQ >>> >>> Check >>> >>> Source 2 >>> >>> 5 >>> >>> MOH_SUB >>> >>> DP_Branch1 >>> >>> Check >>> >>> Source 2 >>> >>> 5 >>> >>> >>> >>> MRG Name >>> >>> Selected Media Resources >>> >>> Use Multicast for MOH Audio >>> >>> MRG_Pub-SW-MMoH >>> >>> MOH_PUB (Multicast) >>> >>> Check >>> >>> MRG_Pub-SW-UMoH >>> >>> MOH_PUB (Multicast) >>> >>> Not Check >>> >>> MRG_Sub-SW-MMoH >>> >>> MOH_SUB (Multicast) >>> >>> Check >>> >>> MRG_Sub-SW-UMoH >>> >>> MOH_SUB (Multicast) >>> >>> Not Check >>> >>> >>> >>> MRGL Name >>> >>> Selected MRG’s >>> >>> MRGL_CorpHQ-Devices >>> >>> MRG_Pub-SW-MMoH >>> >>> MRG_Sub-SW-MMoH >>> >>> MRGL_Branch1-Devices >>> >>> MRG_Pub-SW-UMoH >>> >>> MRG_Sub-SW-UMoH >>> >>> >>> >>> Phone >>> >>> Device Pool >>> >>> MRGL >>> >>> User Hold Audio Source >>> >>> Network Hold Audio Source >>> >>> CorpHQ PH1 >>> 1001 >>> DP_CorpHQ >>> >>> MRGL_CorpHQ-Devices >>> >>> Source 2 >>> >>> Source 1 >>> >>> BR1 PH1 >>> 2001 >>> DP_Branch1 >>> >>> MRGL_Branch1-Devices >>> >>> Source 3 >>> >>> Source 1 >>> >>> >>> >>> Gateways >>> >>> Device Pool >>> >>> CorpHQ_GW >>> >>> DP_CorpHQ >>> >>> Branch1_GW >>> >>> DP_Branch1 >>> >>> >>> >>> >>> >>> Test Results:- >>> >>> >>> >>> Holder >>> >>> Holdee >>> >>> User Hold MoH Played >>> >>> Network MoH Played >>> >>> RTMT Result >>> >>> CorpHQ PH1 >>> >>> BR1 PH1 >>> >>> Yes (Source 2) >>> >>> Yes (Source 1) >>> >>> User Hold (Unicast), Network Hold (Unicast) >>> >>> BR1 PH1 >>> >>> CorpHQ PH1 >>> >>> Yes (Source 3) >>> >>> No (Silence) >>> >>> User Hold (Unicast), Network Hold (Multicast) >>> >>> CorpHQ PH1 >>> >>> CorpHQ PH2 >>> >>> Yes (Source 2) >>> >>> No (Silence) >>> >>> User Hold (Multicast), Network Hold (Multicast) >>> >>> BR1 PH1 >>> >>> BR1 PH2 >>> >>> Yes (Source 3) >>> >>> Yes (Source 1) >>> >>> User Hold (Unicast), Network Hold (Unicast) >>> >>> >>> >>> Here is my CorpHQ Router Configuration…. >>> >>> >>> >>> Ip multicast-routing >>> >>> ! >>> >>> interface FastEthernet0/0 >>> >>> description == To SW1 >>> >>> no ip address >>> >>> duplex auto >>> >>> speed auto >>> >>> ! >>> >>> interface FastEthernet0/0.10 >>> >>> description == Server VLAN >>> >>> encapsulation dot1Q 10 >>> >>> ip address 10.10.100.1 255.255.255.0 >>> >>> ip pim dense-mode >>> >>> ! >>> >>> interface FastEthernet0/0.11 >>> >>> description == Voice VLAN >>> >>> encapsulation dot1Q 11 >>> >>> ip address 10.10.200.3 255.255.255.0 >>> >>> ip pim dense-mode >>> >>> ! >>> >>> interface FastEthernet0/0.12 >>> >>> description == Data VLAN >>> >>> encapsulation dot1Q 12 >>> >>> ip address 10.10.210.1 255.255.255.0 >>> >>> ! >>> >>> interface Serial0/1/0 >>> >>> description == Frame-Relay Circuit to WAN >>> >>> no ip address >>> >>> encapsulation frame-relay >>> >>> no fair-queue >>> >>> service-module t1 timeslots 1-24 >>> >>> cdp enable >>> >>> no frame-relay inverse-arp >>> >>> frame-relay lmi-type ansi >>> >>> ! >>> >>> interface Serial0/1/0.1 point-to-point >>> >>> description == FR To BR1 >>> >>> ip address 10.10.111.1 255.255.255.0 >>> >>> ip pim dense-mode >>> >>> snmp trap link-sta
Re: [OSL | CCIE_Voice] MOH issue
Locations cac allows for 80k to BR1 ? On 29 Feb 2012, at 13:02, Brian Valentine wrote: > Sorry... read too fast. I see it there on the subinterfaces now. Are you > testing via set to set or via pstn? Pstn should need a loopback ro work. > > On Feb 29, 2012 6:59 AM, "Brian Valentine" wrote: > Yes. You arent making pim neighbor relationships over the wan link. > > Enable pim on your wan interfaces. > > On Feb 29, 2012 6:44 AM, "Ashwani" wrote: > Juan, > > Yes igmp-snooping is disabled on switches. I forgot to paste my switch > configuration. Also I have Trans-coder setup for CorpHQ and BR1 site. Also > CUCM MoH is setup for G711 only and Region for CorpHQ and BR1 is allowed > G729. Thanks for looking into this issue. > > Ashwani > > On 2/29/2012 12:14 AM, Juan Lopez wrote: >> >> Ashwani, >> have you turned off 'ip igmp snooping' on the switch? The silence indicates >> a network issue, not a ucm/resource issue. Also note, no mmoh over IPSec >> tunnels. >> >> On 29 Feb 2012, at 05:27, Ashwani wrote: >> >>> Hello Experts, >>> >>> I am trying to do MoH lab but I am not seeing the result as expected. Here >>> is my scenario, relevant configuration and my test results >>> >>> MOH Audio Stream Number >>> >>> MOH Audio Source File >>> >>> Play Continuously >>> >>> Allow Multicasting >>> >>> 1 >>> >>> Source 1 >>> >>> Check >>> >>> Not Check >>> >>> 2 >>> >>> Source 2 >>> >>> Check >>> >>> Check >>> >>> 3 >>> >>> Source 3 >>> >>> Check >>> >>> Not Check >>> >>> >>> >>> MOH Server Name >>> >>> Device Pool >>> >>> Enable Multicast >>> >>> Selected Multicast Audio Sources >>> >>> Max Hops >>> >>> MOH_PUB >>> >>> DP_CorpHQ >>> >>> Check >>> >>> Source 2 >>> >>> 5 >>> >>> MOH_SUB >>> >>> DP_Branch1 >>> >>> Check >>> >>> Source 2 >>> >>> 5 >>> >>> >>> >>> MRG Name >>> >>> Selected Media Resources >>> >>> Use Multicast for MOH Audio >>> >>> MRG_Pub-SW-MMoH >>> >>> MOH_PUB (Multicast) >>> >>> Check >>> >>> MRG_Pub-SW-UMoH >>> >>> MOH_PUB (Multicast) >>> >>> Not Check >>> >>> MRG_Sub-SW-MMoH >>> >>> MOH_SUB (Multicast) >>> >>> Check >>> >>> MRG_Sub-SW-UMoH >>> >>> MOH_SUB (Multicast) >>> >>> Not Check >>> >>> >>> >>> MRGL Name >>> >>> Selected MRG’s >>> >>> MRGL_CorpHQ-Devices >>> >>> MRG_Pub-SW-MMoH >>> >>> MRG_Sub-SW-MMoH >>> >>> MRGL_Branch1-Devices >>> >>> MRG_Pub-SW-UMoH >>> >>> MRG_Sub-SW-UMoH >>> >>> >>> >>> Phone >>> >>> Device Pool >>> >>> MRGL >>> >>> User Hold Audio Source >>> >>> Network Hold Audio Source >>> >>> CorpHQ PH1 >>> 1001 >>> DP_CorpHQ >>> >>> MRGL_CorpHQ-Devices >>> >>> Source 2 >>> >>> Source 1 >>> >>> BR1 PH1 >>> 2001 >>> DP_Branch1 >>> >>> MRGL_Branch1-Devices >>> >>> Source 3 >>> >>> Source 1 >>> >>> >>> >>> Gateways >>> >>> Device Pool >>> >>> CorpHQ_GW >>> >>> DP_CorpHQ >>> >>> Branch1_GW >>> >>> DP_Branch1 >>> >>> >>> >>> >>> >>> Test Results:- >>> >>> >>> >>> Holder >>> >>> Holdee >>> >>> User Hold MoH Played >>> >>> Network MoH Played >>> >>> RTMT Result >>> >>> CorpHQ PH1 >>> >>> BR1 PH1 >>> >>> Yes (Source 2) >>> >>> Yes (Source 1) >>> >>> User Hold (Unicast), Network Hold (Unicast) >>> >>> BR1 PH1 >>> >>> CorpHQ PH1 >>> >>> Yes (Source 3) >>> >>> No (Silence) >>> >>> User Hold (Unicast), Network Hold (Multicast) >>> >>> CorpHQ PH1 >>> >>> CorpHQ PH2 >>> >>> Yes (Source 2) >>> >>> No (Silence) >>> >>> User Hold (Multicast), Network Hold (Multicast) >>> >>> BR1 PH1 >>> >>> BR1 PH2 >>> >>> Yes (Source 3) >>> >>> Yes (Source 1) >>> >>> User Hold (Unicast), Network Hold (Unicast) >>> >>> >>> >>> Here is my CorpHQ Router Configuration…. >>> >>> >>> >>> Ip multicast-routing >>> >>> ! >>> >>> interface FastEthernet0/0 >>> >>> description == To SW1 >>> >>> no ip address >>> >>> duplex auto >>> >>> speed auto >>> >>> ! >>> >>> interface FastEthernet0/0.10 >>> >>> description == Server VLAN >>> >>> encapsulation dot1Q 10 >>> >>> ip address 10.10.100.1 255.255.255.0 >>> >>> ip pim dense-mode >>> >>> ! >>> >>> interface FastEthernet0/0.11 >>> >>> description == Voice VLAN >>> >>> encapsulation dot1Q 11 >>> >>> ip address 10.10.200.3 255.255.255.0 >>> >>> ip pim dense-mode >>> >>> ! >>> >>> interface FastEthernet0/0.12 >>> >>> description == Data VLAN >>> >>> encapsulation dot1Q 12 >>> >>> ip address 10.10.210.1 255.255.255.0 >>> >>> ! >>> >>> interface Serial0/1/0 >>> >>> description == Frame-Relay Circuit to WAN >>> >>> no ip address >>> >>> encapsulation frame-relay >>> >>> no fair-queue >>> >>> service-module t1 timeslots 1-24 >>> >>> cdp enable >>> >>> no frame-relay inverse-arp >>> >>> frame-relay lmi-type ansi >>> >>> ! >>> >>> interface Serial0/1/0.1 point-to-point >>> >>> description == FR To BR1 >>> >>> ip address 10.10.111.1 255.255.255.0 >>> >>> ip pim dense-mode >>> >>> snmp trap link-status >>> >>>
Re: [OSL | CCIE_Voice] MOH issue
Sorry... read too fast. I see it there on the subinterfaces now. Are you testing via set to set or via pstn? Pstn should need a loopback ro work. On Feb 29, 2012 6:59 AM, "Brian Valentine" wrote: > Yes. You arent making pim neighbor relationships over the wan link. > > Enable pim on your wan interfaces. > On Feb 29, 2012 6:44 AM, "Ashwani" wrote: > >> Juan, >> >> Yes igmp-snooping is disabled on switches. I forgot to paste my switch >> configuration. Also I have Trans-coder setup for CorpHQ and BR1 site. >> Also CUCM MoH is setup for G711 only and Region for CorpHQ and BR1 is >> allowed G729. Thanks for looking into this issue. >> >> Ashwani >> >> On 2/29/2012 12:14 AM, Juan Lopez wrote: >> >> Ashwani, >> have you turned off 'ip igmp snooping' on the switch? The silence >> indicates a network issue, not a ucm/resource issue. Also note, no mmoh >> over IPSec tunnels. >> >> On 29 Feb 2012, at 05:27, Ashwani wrote: >> >> Hello Experts, >> >> I am trying to do MoH lab but I am not seeing the result as expected. >> Here is my scenario, relevant configuration and my test results >> >> *MOH Audio Stream Number* >> >> *MOH Audio Source File* >> >> *Play Continuously* >> >> *Allow Multicasting* >> >> 1 >> >> Source 1 >> >> Check >> >> Not Check >> >> 2 >> >> Source 2 >> >> Check >> >> Check >> >> 3 >> >> Source 3 >> >> Check >> >> Not Check >> >> ** ** >> >> *MOH Server Name* >> >> *Device Pool* >> >> *Enable Multicast* >> >> *Selected Multicast Audio Sources* >> >> *Max Hops* >> >> MOH_PUB >> >> DP_CorpHQ >> >> Check >> >> Source 2 >> >> 5 >> >> MOH_SUB >> >> DP_Branch1 >> >> Check >> >> Source 2 >> >> 5 >> >> ** ** >> >> *MRG Name* >> >> *Selected Media Resources* >> >> *Use Multicast for MOH Audio* >> >> MRG_Pub-SW-MMoH >> >> MOH_PUB (Multicast) >> >> Check >> >> MRG_Pub-SW-UMoH >> >> MOH_PUB (Multicast) >> >> Not Check >> >> MRG_Sub-SW-MMoH >> >> MOH_SUB (Multicast) >> >> Check >> >> MRG_Sub-SW-UMoH >> >> MOH_SUB (Multicast) >> >> Not Check >> >> ** ** >> >> *MRGL Name* >> >> *Selected MRG’s* >> >> MRGL_CorpHQ-Devices >> >> MRG_Pub-SW-MMoH >> >> MRG_Sub-SW-MMoH >> >> MRGL_Branch1-Devices >> >> MRG_Pub-SW-UMoH >> >> MRG_Sub-SW-UMoH >> >> ** ** >> >> *Phone* >> >> *Device Pool* >> >> *MRGL* >> >> *User Hold Audio Source* >> >> *Network Hold Audio Source* >> >> CorpHQ PH1 >> 1001 >> >> DP_CorpHQ >> >> MRGL_CorpHQ-Devices >> >> Source 2 >> >> Source 1 >> >> BR1 PH1 >> 2001 >> >> DP_Branch1 >> >> MRGL_Branch1-Devices >> >> Source 3 >> >> Source 1 >> >> ** ** >> >> *Gateways* >> >> *Device Pool* >> >> CorpHQ_GW >> >> DP_CorpHQ >> >> Branch1_GW >> >> DP_Branch1 >> >> ** ** >> >> ** >> ** >> >> *Test Results:-* >> >> ** ** >> >> *Holder* >> >> *Holdee* >> >> *User Hold MoH Played* >> >> *Network MoH Played* >> >> *RTMT Result* >> >> CorpHQ PH1 >> >> BR1 PH1 >> >> Yes (Source 2) >> >> Yes (Source 1) >> >> User Hold (Unicast), Network Hold (Unicast) >> >> BR1 PH1 >> >> CorpHQ PH1 >> >> Yes (Source 3) >> >> No (Silence) >> >> User Hold (Unicast), Network Hold (Multicast) >> >> CorpHQ PH1 >> >> CorpHQ PH2 >> >> Yes (Source 2) >> >> No (Silence) >> >> User Hold (Multicast), Network Hold (Multicast) >> >> BR1 PH1 >> >> BR1 PH2 >> >> Yes (Source 3) >> >> Yes (Source 1) >> >> User Hold (Unicast), Network Hold (Unicast) >> >> ** ** >> >> *Here is my CorpHQ Router Configuration….* >> >> ** ** >> >> Ip multicast-routing >> >> ! >> >> interface FastEthernet0/0 >> >> description == To SW1 >> >> no ip address >> >> duplex auto >> >> speed auto >> >> ! >> >> interface FastEthernet0/0.10 >> >> description == Server VLAN >> >> encapsulation dot1Q 10 >> >> ip address 10.10.100.1 255.255.255.0 >> >> ip pim dense-mode >> >> ! >> >> interface FastEthernet0/0.11 >> >> description == Voice VLAN >> >> encapsulation dot1Q 11 >> >> ip address 10.10.200.3 255.255.255.0 >> >> ip pim dense-mode >> >> ! >> >> interface FastEthernet0/0.12 >> >> description == Data VLAN >> >> encapsulation dot1Q 12 >> >> ip address 10.10.210.1 255.255.255.0 >> >> ! >> >> interface Serial0/1/0 >> >> description == Frame-Relay Circuit to WAN >> >> no ip address >> >> encapsulation frame-relay >> >> no fair-queue >> >> service-module t1 timeslots 1-24 >> >> cdp enable >> >> no frame-relay inverse-arp >> >> frame-relay lmi-type ansi >> >> ! >> >> interface Serial0/1/0.1 point-to-point >> >> description == FR To BR1 >> >> ip address 10.10.111.1 255.255.255.0 >> >> ip pim dense-mode >> >> snmp trap link-status >> >> frame-relay interface-dlci 101 >> >> ! >> >> interface Serial0/1/0.2 point-to-point >> >> description == FR To BR2 >> >> ip address 10.10.112.1 255.255.255.0 >> >> ip pim dense-mode >> >> snmp trap link-status >> >> frame-relay interface-dlci 201 >> >> ! >> >> ** ** >> >> ** ** >> >> *Here is my Branch1 Router Configuration….* >> >> * * >> >> Ip multicast-routing >> >> ! >> >> interface FastEthernet0/0.20 >> >> description == Data VLAN >> >> encapsulation dot1Q 22 >> >>
Re: [OSL | CCIE_Voice] MOH issue
Yes. You arent making pim neighbor relationships over the wan link. Enable pim on your wan interfaces. On Feb 29, 2012 6:44 AM, "Ashwani" wrote: > Juan, > > Yes igmp-snooping is disabled on switches. I forgot to paste my switch > configuration. Also I have Trans-coder setup for CorpHQ and BR1 site. > Also CUCM MoH is setup for G711 only and Region for CorpHQ and BR1 is > allowed G729. Thanks for looking into this issue. > > Ashwani > > On 2/29/2012 12:14 AM, Juan Lopez wrote: > > Ashwani, > have you turned off 'ip igmp snooping' on the switch? The silence > indicates a network issue, not a ucm/resource issue. Also note, no mmoh > over IPSec tunnels. > > On 29 Feb 2012, at 05:27, Ashwani wrote: > > Hello Experts, > > I am trying to do MoH lab but I am not seeing the result as expected. > Here is my scenario, relevant configuration and my test results > > *MOH Audio Stream Number* > > *MOH Audio Source File* > > *Play Continuously* > > *Allow Multicasting* > > 1 > > Source 1 > > Check > > Not Check > > 2 > > Source 2 > > Check > > Check > > 3 > > Source 3 > > Check > > Not Check > > ** ** > > *MOH Server Name* > > *Device Pool* > > *Enable Multicast* > > *Selected Multicast Audio Sources* > > *Max Hops* > > MOH_PUB > > DP_CorpHQ > > Check > > Source 2 > > 5 > > MOH_SUB > > DP_Branch1 > > Check > > Source 2 > > 5 > > ** ** > > *MRG Name* > > *Selected Media Resources* > > *Use Multicast for MOH Audio* > > MRG_Pub-SW-MMoH > > MOH_PUB (Multicast) > > Check > > MRG_Pub-SW-UMoH > > MOH_PUB (Multicast) > > Not Check > > MRG_Sub-SW-MMoH > > MOH_SUB (Multicast) > > Check > > MRG_Sub-SW-UMoH > > MOH_SUB (Multicast) > > Not Check > > ** ** > > *MRGL Name* > > *Selected MRG’s* > > MRGL_CorpHQ-Devices > > MRG_Pub-SW-MMoH > > MRG_Sub-SW-MMoH > > MRGL_Branch1-Devices > > MRG_Pub-SW-UMoH > > MRG_Sub-SW-UMoH > > ** ** > > *Phone* > > *Device Pool* > > *MRGL* > > *User Hold Audio Source* > > *Network Hold Audio Source* > > CorpHQ PH1 > 1001 > > DP_CorpHQ > > MRGL_CorpHQ-Devices > > Source 2 > > Source 1 > > BR1 PH1 > 2001 > > DP_Branch1 > > MRGL_Branch1-Devices > > Source 3 > > Source 1 > > ** ** > > *Gateways* > > *Device Pool* > > CorpHQ_GW > > DP_CorpHQ > > Branch1_GW > > DP_Branch1 > > ** ** > > ** > ** > > *Test Results:-* > > ** ** > > *Holder* > > *Holdee* > > *User Hold MoH Played* > > *Network MoH Played* > > *RTMT Result* > > CorpHQ PH1 > > BR1 PH1 > > Yes (Source 2) > > Yes (Source 1) > > User Hold (Unicast), Network Hold (Unicast) > > BR1 PH1 > > CorpHQ PH1 > > Yes (Source 3) > > No (Silence) > > User Hold (Unicast), Network Hold (Multicast) > > CorpHQ PH1 > > CorpHQ PH2 > > Yes (Source 2) > > No (Silence) > > User Hold (Multicast), Network Hold (Multicast) > > BR1 PH1 > > BR1 PH2 > > Yes (Source 3) > > Yes (Source 1) > > User Hold (Unicast), Network Hold (Unicast) > > ** ** > > *Here is my CorpHQ Router Configuration….* > > ** ** > > Ip multicast-routing > > ! > > interface FastEthernet0/0 > > description == To SW1 > > no ip address > > duplex auto > > speed auto > > ! > > interface FastEthernet0/0.10 > > description == Server VLAN > > encapsulation dot1Q 10 > > ip address 10.10.100.1 255.255.255.0 > > ip pim dense-mode > > ! > > interface FastEthernet0/0.11 > > description == Voice VLAN > > encapsulation dot1Q 11 > > ip address 10.10.200.3 255.255.255.0 > > ip pim dense-mode > > ! > > interface FastEthernet0/0.12 > > description == Data VLAN > > encapsulation dot1Q 12 > > ip address 10.10.210.1 255.255.255.0 > > ! > > interface Serial0/1/0 > > description == Frame-Relay Circuit to WAN > > no ip address > > encapsulation frame-relay > > no fair-queue > > service-module t1 timeslots 1-24 > > cdp enable > > no frame-relay inverse-arp > > frame-relay lmi-type ansi > > ! > > interface Serial0/1/0.1 point-to-point > > description == FR To BR1 > > ip address 10.10.111.1 255.255.255.0 > > ip pim dense-mode > > snmp trap link-status > > frame-relay interface-dlci 101 > > ! > > interface Serial0/1/0.2 point-to-point > > description == FR To BR2 > > ip address 10.10.112.1 255.255.255.0 > > ip pim dense-mode > > snmp trap link-status > > frame-relay interface-dlci 201 > > ! > > ** ** > > ** ** > > *Here is my Branch1 Router Configuration….* > > * * > > Ip multicast-routing > > ! > > interface FastEthernet0/0.20 > > description == Data VLAN > > encapsulation dot1Q 22 > > ip address 10.10.101.1 255.255.255.0 > > ! > > interface FastEthernet0/0.21 > > description == Voice VLAN > > encapsulation dot1Q 21 > > ip address 10.10.201.1 255.255.255.0 > > ip pim dense-mode > > ! > > interface Serial0/1/0 > > description == Frame-Relay Circuit to WAN > > no ip address > > encapsulation frame-relay > > no fair-queue > > service-module t1 timeslots 1-24 > > cdp enable > > no frame-relay inverse-arp > > frame-relay lmi-type ansi > > ! > > interface Serial0/1/0.1 point-to-point > > description == FR To HQ > > ip address 10.10.111.2 255.
Re: [OSL | CCIE_Voice] MOH issue
Source 1 Audio file is not enabled for Multicasting which is used for Network Hold. Try enabling it and see. From: lopez.hernandez.j...@gmail.com Date: Wed, 29 Feb 2012 06:14:06 +0100 To: ash_r...@hotmail.com CC: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] MOH issue Ashwani, have you turned off 'ip igmp snooping' on the switch? The silence indicates a network issue, not a ucm/resource issue. Also note, no mmoh over IPSec tunnels. On 29 Feb 2012, at 05:27, Ashwani wrote: Hello Experts, I am trying to do MoH lab but I am not seeing the result as expected. Here is my scenario, relevant configuration and my test results MOH Audio Stream Number MOH Audio Source File Play Continuously Allow Multicasting 1 Source 1 Check Not Check 2 Source 2 Check Check 3 Source 3 Check Not Check MOH Server Name Device Pool Enable Multicast Selected Multicast Audio Sources Max Hops MOH_PUB DP_CorpHQ Check Source 2 5 MOH_SUB DP_Branch1 Check Source 2 5 MRG Name Selected Media Resources Use Multicast for MOH Audio MRG_Pub-SW-MMoH MOH_PUB (Multicast) Check MRG_Pub-SW-UMoH MOH_PUB (Multicast) Not Check MRG_Sub-SW-MMoH MOH_SUB (Multicast) Check MRG_Sub-SW-UMoH MOH_SUB (Multicast) Not Check MRGL Name Selected MRG’s MRGL_CorpHQ-Devices MRG_Pub-SW-MMoH MRG_Sub-SW-MMoH MRGL_Branch1-Devices MRG_Pub-SW-UMoH MRG_Sub-SW-UMoH Phone Device Pool MRGL User Hold Audio Source Network Hold Audio Source CorpHQ PH1 1001 DP_CorpHQ MRGL_CorpHQ-Devices Source 2 Source 1 BR1 PH1 2001 DP_Branch1 MRGL_Branch1-Devices Source 3 Source 1 Gateways Device Pool CorpHQ_GW DP_CorpHQ
Re: [OSL | CCIE_Voice] MOh Issue
I have been troubleshooting a similar issue, but with my HQ site. Also MoH works when I make a PSTN call to BR1, BR2 but not from internal, BR1->BR2 etc. EJF From: Adil Shaikh To: amit batra Cc: ccie voice Sent: Sunday, September 11, 2011 10:32 PM Subject: Re: [OSL | CCIE_Voice] MOh Issue did you put 'ccm music' command in global config? -adil On Mon, Sep 12, 2011 at 10:14 AM, amit batra wrote: Hello Guys > > I am stuck with this strange thing and for some reason cant get Moh >working on my CME BR2 router..It has always worked in the past Multicast and >Unicast.. >In this particular question, there are no Multicast requirement so i just >configure moh music-on-hold.au command. When i call from PSTN phone to >32143001 and user 3001 put the call on hold i can hear MoH fine.. > >But when user 3001 calls 3002 (Internal call) .. All i hear is a beep...I have >checked. the codec is G711u for sure. > >Can anyone please advice on what i am missing.. > >Thanks .. > >Here is the config .. > >telephony-service > sdspfarm units 3 > sdspfarm transcode sessions 4 > sdspfarm tag 1 BR2-XCODER > no auto-reg-ephone > max-ephones 5 > max-dn 20 no-reg > ip source-address 10.10.202.1 port 2000 > time-zone 23 > voicemail 3600 > max-conferences 8 gain -6 > moh music-on-hold.au > transfer-system full-consult > create cnf-files version-stamp 7960 Sep 11 2011 11:04:38 >! >! >ephone-dn 1 octo-line > number 3001 no-reg primary > description 032143001 > name BR2 Phone 1 > call-forward busy 3600 > call-forward noan 3600 timeout 12 > mwi sip >! >! >ephone-dn 2 octo-line > number 3002 no-reg primary > description 032143002 > name BR2 Phone 2 > call-forward busy 3600 > call-forward noan 3600 timeout 12 > mwi sip >! >! >ephone-dn 3 octo-line > number 3003 no-reg primary > description 032143003 > name BR2 Phone 3 >! >! >ephone 1 > no multicast-moh > device-security-mode none > description 032143001 > mac-address 0026.0B5D.EDFA > button 1:1 >! >! >! >ephone 2 > no multicast-moh > device-security-mode none > description 032143002 > mac-address 0021.A02B.E1C5 > blf-speed-dial 1 5002 label "5002" > button 1:2 2w1 > > > > >___ >For more information regarding industry leading CCIE Lab training, please >visit www.ipexpert.com > >Are you a CCNP or CCIE and looking for a job? Check out >www.PlatinumPlacement.com > -- . . . . _7___|___|_|_|adil.sha...@gmail.com . . ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] MOh Issue
did you put 'ccm music' command in global config? -adil On Mon, Sep 12, 2011 at 10:14 AM, amit batra wrote: > Hello Guys > > I am stuck with this strange thing and for some reason cant get > Moh working on my CME BR2 router..It has always worked in the past > Multicast and Unicast.. > In this particular question, there are no Multicast requirement so i just > configure moh music-on-hold.au command. When i call from PSTN phone to > 32143001 and user 3001 put the call on hold i can hear MoH fine.. > > But when user 3001 calls 3002 (Internal call) .. All i hear is a beep...I > have checked. the codec is G711u for sure. > > Can anyone please advice on what i am missing.. > > Thanks .. > > Here is the config .. > > telephony-service > sdspfarm units 3 > sdspfarm transcode sessions 4 > sdspfarm tag 1 BR2-XCODER > no auto-reg-ephone > max-ephones 5 > max-dn 20 no-reg > ip source-address 10.10.202.1 port 2000 > time-zone 23 > voicemail 3600 > max-conferences 8 gain -6 > moh music-on-hold.au > transfer-system full-consult > create cnf-files version-stamp 7960 Sep 11 2011 11:04:38 > ! > ! > ephone-dn 1 octo-line > number 3001 no-reg primary > description 032143001 > name BR2 Phone 1 > call-forward busy 3600 > call-forward noan 3600 timeout 12 > mwi sip > ! > ! > ephone-dn 2 octo-line > number 3002 no-reg primary > description 032143002 > name BR2 Phone 2 > call-forward busy 3600 > call-forward noan 3600 timeout 12 > mwi sip > ! > ! > ephone-dn 3 octo-line > number 3003 no-reg primary > description 032143003 > name BR2 Phone 3 > ! > ! > ephone 1 > no multicast-moh > device-security-mode none > description 032143001 > mac-address 0026.0B5D.EDFA > button 1:1 > ! > ! > ! > ephone 2 > no multicast-moh > device-security-mode none > description 032143002 > mac-address 0021.A02B.E1C5 > blf-speed-dial 1 5002 label "5002" > button 1:2 2w1 > > > > > ___ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > -- .. . . _7___|___|_|_|adil.sha...@gmail.com . . ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
[OSL | CCIE_Voice] MOh Issue
Hello Guys I am stuck with this strange thing and for some reason cant get Moh working on my CME BR2 router..It has always worked in the past Multicast and Unicast.. In this particular question, there are no Multicast requirement so i just configure moh music-on-hold.au command. When i call from PSTN phone to 32143001 and user 3001 put the call on hold i can hear MoH fine.. But when user 3001 calls 3002 (Internal call) .. All i hear is a beep...I have checked. the codec is G711u for sure. Can anyone please advice on what i am missing.. Thanks .. Here is the config .. telephony-service sdspfarm units 3 sdspfarm transcode sessions 4 sdspfarm tag 1 BR2-XCODER no auto-reg-ephone max-ephones 5 max-dn 20 no-reg ip source-address 10.10.202.1 port 2000 time-zone 23 voicemail 3600 max-conferences 8 gain -6 moh music-on-hold.au transfer-system full-consult create cnf-files version-stamp 7960 Sep 11 2011 11:04:38 ! ! ephone-dn 1 octo-line number 3001 no-reg primary description 032143001 name BR2 Phone 1 call-forward busy 3600 call-forward noan 3600 timeout 12 mwi sip ! ! ephone-dn 2 octo-line number 3002 no-reg primary description 032143002 name BR2 Phone 2 call-forward busy 3600 call-forward noan 3600 timeout 12 mwi sip ! ! ephone-dn 3 octo-line number 3003 no-reg primary description 032143003 name BR2 Phone 3 ! ! ephone 1 no multicast-moh device-security-mode none description 032143001 mac-address 0026.0B5D.EDFA button 1:1 ! ! ! ephone 2 no multicast-moh device-security-mode none description 032143002 mac-address 0021.A02B.E1C5 blf-speed-dial 1 5002 label "5002" button 1:2 2w1___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
Re: [OSL | CCIE_Voice] MOH Issue
It is fixed... I really just wanted to see if the phone would think it is getting MOH at G729 but I put a G711 File on the flash so the sound is better and it worked. I had my MOH server set to the HQ Region to G729 to SiteB, but I had it on port based instead of IP based. SiteB router was ccm-manager music-on-hold call-manager-fallback moh .wav (g711 file type) multicast moh 239.1.1.3 port 16384 route x.x.x.x x.x.x.x I just missed it on the CM. On Wed, Jan 14, 2009 at 2:51 PM, Hardesty, Scott wrote: > > > Could you post your sho run on the router that you are sourcing the MOH > from? If you are getting dead air, that means your CCM is setup correctly > and the issue is pointing to the local MOH configuration. Do you have at > least 1 ephone defined? > > > > Another note, if you had it working with g711 and just changed the moh / > multicast information to reflect g729 you may have to delete the entire > call-manager fallback configuration and paste it back in with the g729 > information. I have run into this in the past. > > > > > > *Scott Hardesty | Cisco Engineer | MidAtlantic | Presidio Networked > Solutions* > > *7601 Ora Glen Drive, Suite 100, Greenbelt, MD 20770 | > sharde...@presidio.com* > > *D: 301.313.2041 | C: 443.789.1219 | www.presidio.com* > > ** > > > > -- > > *From:* ccie_voice-boun...@onlinestudylist.com [mailto: > ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *Jose Gregorio > Linero (jlinero) > *Sent:* Wednesday, January 14, 2009 3:07 PM > *To:* Ryan Trauernicht; Antonio McCarver > *Cc:* ccie_voice@onlinestudylist.com > *Subject:* Re: [OSL | CCIE_Voice] MOH Issue > > > > Hi Ryan: > > > > No it does not, it could be G711. > > > > Regards, > > > > Jose > > > -- > > *From:* ccie_voice-boun...@onlinestudylist.com [mailto: > ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *Ryan Trauernicht > *Sent:* Miércoles, Enero 14, 2009 1:16 PM > *To:* Antonio McCarver > *Cc:* ccie_voice@onlinestudylist.com > *Subject:* Re: [OSL | CCIE_Voice] MOH Issue > > If i set my MOH server to G729 for the remote branch and put a G711 file on > the flash with the following commands: > > > > moh .wav > > multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X > > > > > > I get dead air is that b/c the file type loaded on the flash needs to > be g729? > > > > > > On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver < > amccar...@cciequest.com> wrote: > > Hello group, > I am at the very beginning stages of my lab prep so please forgive me if > this is one of those "come on newbie, you should've known that" questions. I > have read and re-read the MOH section in the CallManager Fundamentals book, > and in the CUCM 7.x SRND and I don't see where either went into detail about > the different mcast addresses 239.1.1.1, .2, or .3. My question is, where > can I look to read up on them and this issue? > > Amp > > > > Quoting Vik Malhi : > > 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. 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. > > 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. > > > > > >
Re: [OSL | CCIE_Voice] MOH Issue
Could you post your sho run on the router that you are sourcing the MOH from? If you are getting dead air, that means your CCM is setup correctly and the issue is pointing to the local MOH configuration. Do you have at least 1 ephone defined? Another note, if you had it working with g711 and just changed the moh / multicast information to reflect g729 you may have to delete the entire call-manager fallback configuration and paste it back in with the g729 information. I have run into this in the past. Scott Hardesty | Cisco Engineer | MidAtlantic | Presidio Networked Solutions 7601 Ora Glen Drive, Suite 100, Greenbelt, MD 20770 | mailto:sharde...@presidio.com D: 301.313.2041 | C: 443.789.1219 | http://www.presidio.com/ From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Jose Gregorio Linero (jlinero) Sent: Wednesday, January 14, 2009 3:07 PM To: Ryan Trauernicht; Antonio McCarver Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] MOH Issue Hi Ryan: No it does not, it could be G711. Regards, Jose From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Ryan Trauernicht Sent: Miércoles, Enero 14, 2009 1:16 PM To: Antonio McCarver Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] MOH Issue If i set my MOH server to G729 for the remote branch and put a G711 file on the flash with the following commands: moh .wav multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X I get dead air is that b/c the file type loaded on the flash needs to be g729? On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver wrote: Hello group, I am at the very beginning stages of my lab prep so please forgive me if this is one of those "come on newbie, you should've known that" questions. I have read and re-read the MOH section in the CallManager Fundamentals book, and in the CUCM 7.x SRND and I don't see where either went into detail about the different mcast addresses 239.1.1.1, .2, or .3. My question is, where can I look to read up on them and this issue? Amp Quoting Vik Malhi : 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. 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. 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.
Re: [OSL | CCIE_Voice] MOH Issue
Hi Ryan: No it does not, it could be G711. Regards, Jose From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Ryan Trauernicht Sent: Miércoles, Enero 14, 2009 1:16 PM To: Antonio McCarver Cc: ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] MOH Issue If i set my MOH server to G729 for the remote branch and put a G711 file on the flash with the following commands: moh .wav multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X I get dead air is that b/c the file type loaded on the flash needs to be g729? On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver wrote: Hello group, I am at the very beginning stages of my lab prep so please forgive me if this is one of those "come on newbie, you should've known that" questions. I have read and re-read the MOH section in the CallManager Fundamentals book, and in the CUCM 7.x SRND and I don't see where either went into detail about the different mcast addresses 239.1.1.1, .2, or .3. My question is, where can I look to read up on them and this issue? Amp Quoting Vik Malhi : 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. 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. 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.
Re: [OSL | CCIE_Voice] MOH Issue
My fault monday mistake! I had it based on port based and not IP based. All working now. On Wed, Jan 14, 2009 at 1:16 PM, Ryan Trauernicht wrote: > home lab that I pulled the sample audio from the MOH folder. I set it to > G711only and change the IP address to 239.1.1.1 and all is well. > > > On Wed, Jan 14, 2009 at 12:44 PM, Vik Malhi wrote: > >> Can you post the output of debug ccm-m music all. >> >> Check that the MOH is being active using debug ephone moh. >> >> Dead air is better than tone. CCM thinks everything is working so the >> problem is lying in the spoofing part. >> >> I don't think it is anything to do with your MOH file- have you tried it >> with the music-on-hold.au that is provided? >> >> >> -- >> 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: *Ryan Trauernicht >> *Date: *Wed, 14 Jan 2009 12:15:47 -0600 >> *To: *Antonio McCarver >> *Cc: * >> *Subject: *Re: [OSL | CCIE_Voice] MOH Issue >> >> If i set my MOH server to G729 for the remote branch and put a G711 file >> on the flash with the following commands: >> >> moh .wav >> multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X >> >> >> I get dead air is that b/c the file type loaded on the flash needs to >> be g729? >> >> >> >> On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver < >> amccar...@cciequest.com> wrote: >> >> Hello group, >> I am at the very beginning stages of my lab prep so please forgive me if >> this is one of those "come on newbie, you should've known that" questions. I >> have read and re-read the MOH section in the CallManager Fundamentals book, >> and in the CUCM 7.x SRND and I don't see where either went into detail about >> the different mcast addresses 239.1.1.1, .2, or .3. My question is, where >> can I look to read up on them and this issue? >> >> Amp >> >> >> Quoting Vik Malhi : >> >> 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. 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. >> >> 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. >> >> >> >> >> >> >
Re: [OSL | CCIE_Voice] MOH Issue
home lab that I pulled the sample audio from the MOH folder. I set it to G711only and change the IP address to 239.1.1.1 and all is well. On Wed, Jan 14, 2009 at 12:44 PM, Vik Malhi wrote: > Can you post the output of debug ccm-m music all. > > Check that the MOH is being active using debug ephone moh. > > Dead air is better than tone. CCM thinks everything is working so the > problem is lying in the spoofing part. > > I don't think it is anything to do with your MOH file- have you tried it > with the music-on-hold.au that is provided? > > > -- > 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: *Ryan Trauernicht > *Date: *Wed, 14 Jan 2009 12:15:47 -0600 > *To: *Antonio McCarver > *Cc: * > *Subject: *Re: [OSL | CCIE_Voice] MOH Issue > > If i set my MOH server to G729 for the remote branch and put a G711 file on > the flash with the following commands: > > moh .wav > multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X > > > I get dead air is that b/c the file type loaded on the flash needs to > be g729? > > > > On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver < > amccar...@cciequest.com> wrote: > > Hello group, > I am at the very beginning stages of my lab prep so please forgive me if > this is one of those "come on newbie, you should've known that" questions. I > have read and re-read the MOH section in the CallManager Fundamentals book, > and in the CUCM 7.x SRND and I don't see where either went into detail about > the different mcast addresses 239.1.1.1, .2, or .3. My question is, where > can I look to read up on them and this issue? > > Amp > > > Quoting Vik Malhi : > > 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. 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. > > 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. > > > > > >
Re: [OSL | CCIE_Voice] MOH Issue
Can you post the output of debug ccm-m music all. Check that the MOH is being active using debug ephone moh. Dead air is better than tone. CCM thinks everything is working so the problem is lying in the spoofing part. I don¹t think it is anything to do with your MOH file- have you tried it with the music-on-hold.au that is provided? -- 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: Ryan Trauernicht Date: Wed, 14 Jan 2009 12:15:47 -0600 To: Antonio McCarver Cc: Subject: Re: [OSL | CCIE_Voice] MOH Issue If i set my MOH server to G729 for the remote branch and put a G711 file on the flash with the following commands: moh .wav multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X I get dead air is that b/c the file type loaded on the flash needs to be g729? On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver wrote: > Hello group, > I am at the very beginning stages of my lab prep so please forgive me if this > is one of those "come on newbie, you should've known that" questions. I have > read and re-read the MOH section in the CallManager Fundamentals book, and in > the CUCM 7.x SRND and I don't see where either went into detail about the > different mcast addresses 239.1.1.1, .2, or .3. My question is, where can I > look to read up on them and this issue? > > Amp > > > Quoting Vik Malhi : > >> 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. 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. >> >> 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. > >
Re: [OSL | CCIE_Voice] MOH Issue
If i set my MOH server to G729 for the remote branch and put a G711 file on the flash with the following commands: moh .wav multicast moh 239.1.1.3 port 16384 route X.X.X.X X.X.X.X I get dead air is that b/c the file type loaded on the flash needs to be g729? On Wed, Jan 14, 2009 at 12:11 PM, Antonio McCarver wrote: > Hello group, > I am at the very beginning stages of my lab prep so please forgive me if > this is one of those "come on newbie, you should've known that" questions. I > have read and re-read the MOH section in the CallManager Fundamentals book, > and in the CUCM 7.x SRND and I don't see where either went into detail about > the different mcast addresses 239.1.1.1, .2, or .3. My question is, where > can I look to read up on them and this issue? > > Amp > > > Quoting Vik Malhi : > > 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. 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. >> >> 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. >> > > >
Re: [OSL | CCIE_Voice] MOH Issue
Hello group, I am at the very beginning stages of my lab prep so please forgive me if this is one of those "come on newbie, you should've known that" questions. I have read and re-read the MOH section in the CallManager Fundamentals book, and in the CUCM 7.x SRND and I don't see where either went into detail about the different mcast addresses 239.1.1.1, .2, or .3. My question is, where can I look to read up on them and this issue? Amp Quoting Vik Malhi : 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. 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. 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.
Re: [OSL | CCIE_Voice] MOH Issue
Hi Vik, My response/querry in between lines to your response please...I hv have Q's??? --- On Wed, 1/14/09, Vik Malhi wrote: From: Vik Malhi Subject: Re: [OSL | CCIE_Voice] MOH Issue To: "Alex" 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.3then 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 Date: Wed, 14 Jan 2009 13:58:36 - To: Vik Malhi Cc: 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-Dem
Re: [OSL | CCIE_Voice] MOH Issue
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. 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. 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 Date: Wed, 14 Jan 2009 13:58:36 - To: Vik Malhi Cc: 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_guid e09186a00802d1c31.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 > Date: Wed, 14 Jan 2009 16:13:35 +1100 > To: Christian Hennrich > Cc: , "Kumar, Narinder" > > Subject: Re: [OSL | CCIE_Voice] MOH Issue > > Alex, >
Re: [OSL | CCIE_Voice] MOH Issue
239.1.1.3 configured as base IP for MOH server, "multicast moh 239.1.1.3" on
SRST router and no G.729 for IPVMSA is what I was talking about.
Rgds
Alex
- Original Message -
From: kamal yousaf
To: Alex
Cc: ccie_voice@onlinestudylist.com
Sent: Wednesday, January 14, 2009 3:10 PM
Subject: Re: [OSL | CCIE_Voice] MOH Issue
That means you will use 239.1.1.1 as Multicast IP on your SRST router and NOT
239.1.1.3 as your previous email suggests.
Pls Correct me if i am wrong !
On Thu, Jan 15, 2009 at 12:44 AM, Alex wrote:
Kamal,
According to task wording below: "Between Site A and Site B only g729
allowed" and "Site B will receive multicast MOH from router flash, no multicast
traffic allowed between Ste A and SiteB"
- I take it as MOH from Site B router flash for Site B IP phones can
actually use g711 and wouldn't bother enabling g729 for MOH. This requires
placing MOH servers in G.711-only region/DP as per
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a00803f8950.shtml
which I haven't mentioned in my previous email.
Rgds
Alex
- Original Message -
From: kamal yousaf
To: Christian Hennrich
Cc: Alex ; ccie_voice@onlinestudylist.com ; Kumar, Narinder
Sent: Wednesday, January 14, 2009 5:13 AM
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_voice@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,
Re: [OSL | CCIE_Voice] MOH Issue
Hi Alex:
When you have enabled G729 in IPVMSA CCM instructs the IP Phones to join a
specific multicast group, it depends on what you have configured in the MOH
server, in the case you are talking about, you have configured to increment IP
Address, then the IP Phones will join the multicast group 239.1.1.3, no matter
the moh from the flash is G711, the IP Phones will try to join the group, and
due to the fact you have configured multicast moh with that IP address and the
specific port with route to the Voice VLAN Ip address and the Loopback IP
address, the result will be that MOH will be streaming to the IP Phones in site
B.
Regards,
Jose
From: ccie_voice-boun...@onlinestudylist.com
[mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Alex
Sent: Miércoles, Enero 14, 2009 8:59 AM
To: Vik Malhi
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
Date: Wed, 14 Jan 2009 16:13:35 +1100
To: Christian Hennrich
Cc: , "Kumar, Narinder"
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 M
Re: [OSL | CCIE_Voice] MOH Issue
That means you will use 239.1.1.1 as Multicast IP on your SRST router and NOT 239.1.1.3 as your previous email suggests. Pls Correct me if i am wrong ! On Thu, Jan 15, 2009 at 12:44 AM, Alex wrote: > Kamal, > According to task wording below: "Between Site A and Site B only g729 > allowed" and "Site B will receive multicast MOH from router flash, no > multicast traffic allowed between Ste A and SiteB" > - I take it as MOH from Site B router flash for Site B IP phones can > actually use g711 and wouldn't bother enabling g729 for MOH. This requires > placing MOH servers in G.711-only region/DP as per > http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a00803f8950.shtml > which > I haven't mentioned in my previous email. > Rgds > Alex > > - Original Message - > > *From:* kamal yousaf > *To:* Christian Hennrich > *Cc:* Alex ; ccie_voice@onlinestudylist.com ; Kumar, > Narinder > *Sent:* Wednesday, January 14, 2009 5:13 AM > *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_voice@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
Re: [OSL | CCIE_Voice] MOH Issue
Re: [OSL | CCIE_Voice] MOH IssueVik,
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
To: kamal yousaf ; Christian Hennrich
Cc: ccie_voice@onlinestudylist.com ; Kumar,Narinder
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
Date: Wed, 14 Jan 2009 16:13:35 +1100
To: Christian Hennrich
Cc: , "Kumar, Narinder"
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_voice@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
***
Re: [OSL | CCIE_Voice] MOH Issue
Kamal,
According to task wording below: "Between Site A and Site B only g729 allowed"
and "Site B will receive multicast MOH from router flash, no multicast traffic
allowed between Ste A and SiteB"
- I take it as MOH from Site B router flash for Site B IP phones can actually
use g711 and wouldn't bother enabling g729 for MOH. This requires placing MOH
servers in G.711-only region/DP as per
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a00803f8950.shtml
which I haven't mentioned in my previous email.
Rgds
Alex
- Original Message -
From: kamal yousaf
To: Christian Hennrich
Cc: Alex ; ccie_voice@onlinestudylist.com ; Kumar, Narinder
Sent: Wednesday, January 14, 2009 5:13 AM
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_voice@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 2
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 Date: Wed, 14 Jan 2009 16:13:35 +1100 To: Christian Hennrich Cc: , "Kumar, Narinder" 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_voice@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
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_voice@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 acontrol 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 ne
Re: [OSL | CCIE_Voice] MOH Issue
Hi, have you configured at least max-dn 1, max-ephone 1? For me that was mostly the problem why the moh was not played. Also do a show ephone summary and see what is happening with the moh file. Then do also a debug ephone moh and a dbug ccm-manager music-on-hold. HTH 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_voice@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 acontrol 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:mul
Re: [OSL | CCIE_Voice] MOH Issue
If you want to play a G711 file (which is required) on a G729 stream you need to change your multicast address to +2... 239.1.1.1 (base in CM) you would need 239.1.1.3 on the router. Also dont forget the "ccm-manager music-on-hold" command. Thanks, Ryan Trauernicht 2009/1/13 > create a g711 only region put moh in it. moh to sb will be g711 > > *"Kumar, Narinder" * wrote: > > The file in flash is g711 > > moh SampleAudioSource.ULAW.wav > > > *From:* saralilin2...@yahoo.co.jp [mailto:saralilin2...@yahoo.co.jp] > *Sent:* Tuesday, 13 January 2009 11:44 PM > *To:* Kumar, Narinder; ccie_voice@onlinestudylist.com > *Subject:* Re: [OSL | CCIE_Voice] MOH Issue > > > flash moh only play g711 not g729 > *"Kumar, Narinder" * wrote: > > 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 acontrol 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
Re: [OSL | CCIE_Voice] MOH Issue
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 To: 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 acontrol 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 Leav
Re: [OSL | CCIE_Voice] MOH Issue
create a g711 only region put moh in it. moh to sb will be g711 "Kumar, Narinder" wrote: The file in flash is g711 moh SampleAudioSource.ULAW.wav From: saralilin2...@yahoo.co.jp [mailto:saralilin2...@yahoo.co.jp] Sent: Tuesday, 13 January 2009 11:44 PM To: Kumar, Narinder; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] MOH Issue flash moh only play g711 not g729 "Kumar, Narinder" wrote: 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 acontrol 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.
Re: [OSL | CCIE_Voice] MOH Issue
The file in flash is g711 moh SampleAudioSource.ULAW.wav From: saralilin2...@yahoo.co.jp [mailto:saralilin2...@yahoo.co.jp] Sent: Tuesday, 13 January 2009 11:44 PM To: Kumar, Narinder; ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] MOH Issue flash moh only play g711 not g729 "Kumar, Narinder" wrote: 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 acontrol 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 CONFIDENTIALI
Re: [OSL | CCIE_Voice] MOH Issue
flash moh only play g711 not g729 "Kumar, Narinder" wrote: 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 acontrol 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 sol
[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 acontrol 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 messa
