Handleiding voor configuratie, configuratie en probleem in CUBE
Inhoud
Inleiding
In dit document worden bediening, configuratie en probleemoplossing beschreven voor Multicast Music-on-Hold (MoH) door Cisco Unified Border Element (CUBE).
Hoewel dit document zich richt op de multicast Music-on-Hold (MoH), wordt er een substantieel deel gewijd aan de beschrijving van de manier waarop MoH in het algemeen werkt. Deze extra informatie helpt een basiskennis voor het begin op te bouwen om de kwesties die specifiek zijn voor MoH beter te herkennen en te begrijpen.
Voorwaarden
Vereisten
Er zijn geen specifieke vereisten van toepassing op dit document.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Achtergrond
MoH-Overzicht
MoH wordt afgespeeld wanneer een beller in de hold wordt gezet. Gespreksbeheer wordt geïnitieerd door de gebruiker of door het netwerk wanneer een aanvullend servicetechniek wordt geïmplementeerd, zoals de oproep vooruit of de overdracht. Het eerste wordt door de gebruiker geïnitieerde hold, user-hold of user hold genoemd. Deze laatste wordt aangeduid als door het netwerk geïnitieerde hold, network-hold of network hold.
Hier is een review van hoe MoH werkt met Time Division Multiplexing (TDM) gateways. Dit beeld illustreert de componenten en verbindingen die bij een call-hold scenario betrokken zijn:
Om een call on-hold te kunnen plaatsen is een proces in twee stappen nodig. Dit beeld illustreert de twee betrokken stappen:
MoH-bronnen
De gebruiker die een telefoontje in het hold-hold stelt wordt ook de houder genoemd, en de gebruiker die wordt gezet (en MoH hoort) wordt de houder genoemd. Elke partij beslist over bepaalde aspecten van de muziek die wordt gespeeld.
De muziekbron wordt bepaald door de houder. De bepaling volgt deze hiërarchie:
- De muziekbron wordt ingesteld op de naam van het domein (DN)
- De videobron op het apparaat ingesteld
- De muziekbron op het apparaatprofiel (alleen gebruikershold-muziekbron)
- De muziekbron op mondiaal niveau (serviceparameter, of voorbeeld)
Er zijn twee sets muziekbronnen, genaamd user-hold en network-hold. Wanneer er naar een muziekbron wordt verwezen, kan dat een gebruikershold-or of netwerk-hold-muziekbron betekenen.
MoH-endpoints
Voor MoH doeleinden is het eindpunt aan de kant van CUCM de MoH server. Dit is belangrijk om te begrijpen, omdat de bepaling van de codec (gebaseerd op de configuratie van de interregionale codec) is gebaseerd op:
- Het MoH-servergebied
- De boomstam/het toegangsterrein
De algemene aanbeveling is om de MoH-server een speciaal gebied toe te wijzen, zodat interregionale codec tussen dat gebied en alle andere regio's g.711 is (of een andere codec die u voor MoH wilt uitstromen).
Vanuit het CUCM-perspectief zijn de eindpunten die bij de oproep betrokken zijn niet de twee telefoons, maar eerder:
- IP-telefoon geregistreerd op CUCM
- De gateway/CUBE
Op deze manier behandelt CUCM de stam die naar de poort/CUBE wijst als het eindpunt, en onderzoekt het de middelen die er aan gekoppeld zijn om te bepalen hoe de muziekstroom moet worden teruggegeven.
MoH VoIP-protocol
MoH is per definitie een eenrichtingsgesprek. Hoe dit wordt aangegeven, is afhankelijk van het gebruikte VoIP-protocol. Bijvoorbeeld, op SIP, wordt dit overgebracht via de directie eigenschap. Op H.323 specificeert CUCM 0000000 als het netwerkadres en 0 als de poort (tsapIdentifier) van de MoH-server in het H.245 Open Logical Channel ACK (OLCAck)-bericht.
In call stromen die CUBE impliceren heeft het CUCM geen kennis van het aanroep-been tussen CUBE en Internet Telephony Service Provider (ITSP). Het CUCM heeft alleen betrekking op het aanroep-been tussen de IP-telefoon en de SIP-romp (dat naar CUBE leidt).
Het proces van signaleren voor MoH lijkt op signaleren voor een nieuw gesprek, met een beperkt bereik. In SIP vindt de discussie bijvoorbeeld plaats binnen de context van de reeds bestaande dialoog.[1]
Media Stream uitschakelen
De eerste stap in het eerder genoemde tweestappenproces is om de mediastroom uit te schakelen.
Deze afbeelding illustreert hoe de mediastroom in SIP is uitgeschakeld:
SIP-implementaties verschillen van mening over of één of beide eigenschappen (?a=? en?C=IN ?) worden gebruikt om aan te geven dat de mediastroom wordt uitgeschakeld.
Deze afbeelding illustreert hoe de mediastroom in H.323 is uitgeschakeld:
Connect met MoH
De tweede stap in het eerder genoemde tweestappenproces is de aansluiting op MoH. Zodra de audio stream is uitgeschakeld, geeft CUCM signalen af van de eenvoudige MoH-conversatie waardoor de houder naar de MoH-bron luistert.
Als onderdeel van dit proces houdt CUCM rekening met de mediafuncties van het bedrijf en de Media Resource Group List (MRGL) die bij de stam zijn aangesloten voordat het de parameters voor streaming bepaalt. Aldus is signalering altijd uitgesteld (DO)[2] (in SIP).
Het werkelijke aantal INVITE-transacties varieert. CUCM sluit bijvoorbeeld de houder aan op MoH met slechts één DO INVITE-transactie. Als alternatief wordt de DO INVITE gebruikt om de mediacapaciteit van de houder te verzamelen, en wordt een volgende EO INVITE gebruikt om de houder daadwerkelijk aan MoH te verbinden.
Dit beeld illustreert de transactie voor SIP:
Dit beeld illustreert de transactie voor H.323:
Dit beeld illustreert de signaleringsberichtvolgorde in een interworking-omgeving (wanneer een kant van CUBE SIP is en de andere kant H.323 bijvoorbeeld):
Wanneer Media Resources in een oproep worden gebruikt
Media Resources (MediaTermination Point (MTP)/Transcoders) beschermen het CUBE-to-IT Service Provider (ITSP) aanroepen-been voor het grootste deel. Wanneer een mediabron in een verbinding met CUBE wordt gebruikt, omvat signalering voor MoH hoofdzakelijk Skinny Client Control Protocol (SCCP)-berichten tussen CUCM en de Media Resource. Merk op dat het de media resource is die in de gaten wordt gehouden, niet de CUBE stam. Nadat de MTP/Transcoder is gesignaleerd om naar MoH (uitgaande van SIP) te luisteren, stuurt CUCM een SIP-UPDATE-bericht naar CUBE. Dit werkt de branch parameter bij, die de nieuwe transactie (het MOH gesprek) identificeert.
Hervat de oproep
Het hervatten proces is vergelijkbaar met het Hold proces, behalve dat de volgorde wordt omgekeerd:
- De huidige geluidsstream wordt uitgeschakeld.
- Een andere DO REINVITE wordt verzonden om de houder opnieuw aan de telefoon te verbinden die de vraag op zijn greep plaatste.
SDP-kenmerk
De eigenschap X-cisco-media:umoh in het Session Description Protocol (SDP) is geïntroduceerd om MoH-signalering over Inter-Cluster Trunks (ICT’s)[3] te vereenvoudigen. Met samenwerking tussen endpoints die verschillende protocollen gebruiken, voert CUCM vaak ongemakkelijke en intermediaire signalering uit die niet-intuïtief is. Om het giswerk te vermijden, en het signaleren context-expliciet te maken, wordt een eigen SDP-eigenschap, genaamd X-cisco-media, gebruikt.
Met CUCM versies 8.5 en hoger kan MoH [4] worden gesignaleerd terwijl deze eigenschap is ingesteld op Unicast Music on Hold (UMoH) of MoH, waardoor het vertrouwen op een neppoortwaarde wordt weggenomen om een MoH-scenario aan te geven voor de partij die in hechtenis wordt gehouden.
MoH op CUBE
Met CUBE blijft het basisproces hetzelfde. is het echter belangrijk om in overweging te nemen dat [5] CUBE MoH niet transcodeert tot Cisco IOS? Versie 15.3T. Dit betekent dat u voorzichtig moet zijn met de factoren die de codec selectie in het CUCM-to-CUBE-been beïnvloeden zodat er geen transcoder nodig is.
Codec-overwegingen
In het algemeen hebben verschillende factoren een invloed op de codec die gebruikt wordt in het CUCM-to-CUBE-been, maar deze overwegingen zijn van toepassing op MoH:
- MoH kan niet worden getranscodeerd.[5]
- MoH klinkt alleen goed met G.711.
MoH
MaoH behoudt systeembronnen en bandbreedte. Multicast biedt meerdere gebruikers de mogelijkheid om dezelfde audio bronstroom te gebruiken om muziek op het scherm te zetten. MaoH is wenselijk in elk bedrijfsnetwerk waar de bandbreedtebesparingen belangrijk zijn.
Hier zijn een paar zorgen en problemen als CUBE opteert voor H via het internet naar ITSP:
- Bereik van multicast verkeer - Cisco gebruikt het bereik 239.0.0 tot 239.255.255.255 voor multicast muziek. Dit bereik is bekend als administratief bekeken adressen. Dit blok wordt als een particulier blok beschouwd, hetgeen betekent dat het door ondernemingsnetwerken wordt gebruikt en nooit buiten de onderneming mag worden doorgestuurd. De grensrouters worden gewoonlijk dienovereenkomstig geconfigureerd.
- Multicast via VPN - IP security biedt standaard geen ondersteuning voor MoH.
Dit is hoe CUBE MMoH ondersteunt:
- CUBE ontvangt de MoH-pakketten van de MoH-server.
- Het converteert de pakketten naar unicast IP-pakketten.
- CUBE stuurt de pakketten naar ITSP.
Manipulatie van SIP-directiekenmerken
Zoals beschreven in RFC 3264:
"Als een sessiebeschrijving een multicast mediaspeler bevat die als ontvangen (verzenden) slechts in de lijst staat, betekent dit dat de deelnemers, inclusief de aanbieder en het antwoord, alleen op die stream kunnen ontvangen (verzenden). Dit wijkt af van de eenbladige visie, waarin de directionaliteit verwijst naar de mediastroom tussen aanbieder en antwoordster. Afgezien van die verduidelijking zijn de semantiek van een aangeboden multicaststream precies zoals beschreven in RFC 2327 [1]"
Wanneer CUCM een nieuw-INVITE met een multicast IP-adres verstuurt, stelt het de richtingeigenschap dan in op recv; omdat CUBE de multicast-pakketten echter naar eenastpakketten converteert, moet zij de richteigenschap alleen op de poot met ITSP instellen.
Dit beeld illustreert de logica:
Adresmanipulatie
In de DO[6] wordt opnieuw GEÏNFORMEERD om de ITSP-beller aan de MoH-bron te verbinden, stuurt CUBE haar eigen IP-adres in het SIP SDP C=IN-veld. Dit is een eenastadres.
Deze afbeelding geeft de end-to-end weergave:
Stream van een Flash
Met TDM gateways, worden de extra WAN-bandbreedtebesparingen verwezenlijkt door de multicast muziek recht vanaf de gateway te streamen. Dus als de MoH server op het hoofdkwartier is, en de gateway op een verre tak over een WAN-verbinding is, hoeft multicast verkeer dat MoH vervoert niet het WAN (van het hoofdkwartier naar de tak) over te steken en waardevolle WAN-bandbreedte te gebruiken.
CUBE is een voorziening aan de bovenkant van de romp die niet in staat is om MoH te streamen, dat afkomstig is van de lokale flitser of via een analoge TDM-interface. Het is nog mogelijk om WAN-bandbreedte te realiseren. Dit wordt bereikt met gebruik van een andere spraak-enabled router in de afstandsbediening als bron van de MoH-stroom. Deze router stroomt MoH uit de flitser. CUBE kan vervolgens worden gesignaleerd om deze pakketten te ontvangen, ze te converteren en in te voeren als unicast-pakketten.
Stream vanuit een LiveFed
Om uit een bewegend apparaat te kunnen stromen, moet een andere router worden geconfigureerd omdat CUBE geen lijnequalizer is, zoals in de vorige sectie wordt besproken.
Configuratie
In dit gedeelte wordt beschreven hoe u MoH kunt configureren op switches die geschikt zijn voor CUBE, CUCM en L3.
MaoH instellen op CUBE
Gebruik deze opdrachten om MMoH op CUBE te configureren:
ccm-manager music-on-hold
ip multicast-routing
MoH configureren op CUCM
Volg deze stappen om MoH op CUCM te configureren:
- Schakel multicast in op de MoH-bron, MoH-server en Media Resource Group (MRG).
- Wijs een MRGL aan de romp toe met de MRG ingesteld in stap 1.
- Configuratie van de codec in IP spraak-streaming toepassingsservicparameters.
MoH configureren op L3-bare Switches
Gebruik deze opdrachten om MMoH te configureren op L3-compatibele switches:
ip routing
ip multicast-routing
Wanneer MTP in een Bel wordt gebruikt
MTP's ondersteunen multicast muziek niet. De houder ontvangt alleen dode lucht.[7]
Prestatieoverwegingen
Alle MMOH-pakketten worden verwerkt in Cisco IOS geschakeld. Dit is fijn voor kleine implementaties, maar heeft een aanzienlijk effect op de prestaties van CUBE voor grote installaties.
Beperkingen
Hier volgt een lijst met beperkingen voor het gebruik van MMoH:
- CUBE moet minimaal 310 minuten zijn op Cisco IOS versie 15.2(2)T.
- MMoH wordt niet ondersteund op AS54xx.
- MoH wordt niet ondersteund op ISR-G1s (28xx, 38xx Series)
- Let op de codecs die worden ondersteund.
Problemen oplossen
Gebruik deze sectie om problemen op te lossen.
Opdrachten tonen en Debug
Hier is een lijst van tonen en debug opdrachten, en hun betekenissen:
- Toon ccm-manager muziek - Helpt te bevestigen dat CUBE weet waar ze naar multicast muziekpakketten moet luisteren en ook of deze ontvangen. .
R1#show ccm-manager music
Current active multicast sessions : 1
Multicast RTP port Packets Call Codec Incoming
Address number in/out id Interface
===================================================================
239.176.201.1 16384 956/956 237 g711ulaw Se0/1/0 - ip igmp leden tonen - gebruikt om te controleren of CUBE zich succesvol bij de multicast groep aansluit wanneer gesignaleerd om naar multicast muziek te luisteren.
- Deze drie opdrachten worden gebruikt om de onderhandelde codec, IP-adres en poortnummers van de endpoints te controleren:
Show call active voice compact
Hier is een voorbeelduitvoer van de eerste opdracht:
Show voip rtp conn
Show sip callsR1#show call active voice compact
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
Total call-legs: 2
236 ANS T53 g711ulaw VOIP P1003 239.176.201.1:16384
237 ORG T53 g711ulaw VOIP P919789362814 200.200.200.2:17808 - Bel actieve stembriefje- Geef deze opdracht uit als de aanroep in de stand is om te controleren of de toename van de rx/tx is geteld.
0 : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
+4190 pid:1000 Answer 1003 connected
dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 239.176.201.1:16384 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
0 : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
+4190 pid:2000 Originate 919789362814 connected
dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
IP 200.200.200.2:17808 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a - Toon perf query class "Cisco MOH Devices" - Deze CUCM CLI opdracht wordt gebruikt om snel te controleren of een MoH resource is toegewezen en wat voor soort (unicast of multicast). Deze opdracht is niet erg nuttig wanneer u meerdere aanroepen niet-hold hebt, aangezien de tellingen dynamisch veranderen wanneer de aanroepen niet-hold worden gehouden en hervat.
admin:show perf query class "Cisco MOH Device"
==>query class :
- Perf class (Cisco MOH Device) has instances and values:
MOH_2 -> MOHHighestActiveResources = 0
MOH_2 -> MOHMulticastResourceActive = 0
MOH_2 -> MOHMulticastResourceAvailable = 250000
MOH_2 -> MOHOutOfResources = 1
MOH_2 -> MOHTotalMulticastResources = 250000
MOH_2 -> MOHTotalUnicastResources = 250
MOH_2 -> MOHUnicastResourceActive = 0
MOH_2 -> MOHUnicastResourceAvailable = 250 - Debug ccm-manager muziek-on-hold - Deze opdracht wordt gebruikt om te bepalen hoe de aanroepen worden gewijzigd (wanneer u de huidige audio uitschakelt en MoH bijvoorbeeld aansluit), en om te controleren of CUBE zich aansluit bij de IGMP-groep (Internet Group Management Protocol) zoals aangegeven door CUCM.
- IP-pakketten reinigen - Deze opdracht wordt gebruikt als alternatief voor Wireshark voor controles. Deze opdracht kan echter snel overweldigen naar de CPU. Gebruik het enkel wanneer dit absoluut noodzakelijk is; zet de houtkap van de console uit en voer deze niet meer dan een seconde.
Scenario 1
Symptoom - Een vraag van het Public Switched Telephone Network (PSTN) stelt fijn vast met bidirectionele audio. Wanneer de IP-telefoon de PSTN-beller in-hold plaatst en vervolgens het gesprek hervat, levert één-weg audioresultaten op: De IP-telefoon hoort de audio van PSTN, maar de PSTN-gebruiker kan de IP-telefoon niet horen.
Zorg er eerst voor dat het vereisen van SDP Inactive Exchange voor de verandering van media halverwege de oproep niet uitgeschakeld is in de betreffende SIP-stam[5]. Dit is wat CUCM in staat stelt om een opnieuw INVITE te verzenden met a=inactive in SDP om het bestaande mediapad te doorbreken.
Wanneer de oproep op het scherm wordt gezet, stuurt CUCM geen herINVITE met een inactieve SDP om het mediapad te breken als de Send-ontvangstselectie SDP in het aanvinkvakje van de vraag INVITE is ingeschakeld voor de SIP-stam[8]. Die configuratie wordt alleen gecontroleerd voor apparaten die geen volledig aanbod (send-recv) kunnen bieden nadat de mediamodus op inactief is ingesteld.
Hier zijn beelden die de beschikbare vinkjes illustreren:
Scenario 2
Symptoom - Er is alleen een tint wanneer de bellers in de hold worden geplaatst in plaats van MoH.
In het algemeen duidt dit erop dat CUCM MMoH niet heeft toegewezen.
- Gebruik de show perf query class? Cisco MOH device? CUCM CLI-opdracht om te controleren of de stappen van de MOHOOut-bronnen tellen.
- Zorg ervoor dat multicast is ingeschakeld op de hoofdbron, server en groep.
Scenario 3
Symptoom - Er wordt alleen dode lucht gehoord wanneer de beller in het ruim wordt geplaatst.
Zorg ervoor dat:
- De multicast routing wordt op de CUBE en andere routers in het audiopad ingeschakeld.
- IP-routing en multicast-routing worden ingeschakeld op de L3-switches in het audiopad.
- De ttl (hoptelling) wordt ingesteld op de MoH server op CUCM en is groot genoeg om de hop te bedekken.
- Als een transcoder vereist is, wordt deze met succes toegewezen.
- De lijst met codecs die in de IP Voice Streaming Application zijn geconfigureerd, ondersteunt de codec die voor MoH wordt gebruikt.
Scenario 4
Symptoom - Een vraag faalt in de flow-rondom modus voor Gespreksbeheer en -hergebruik.
Om doorstroming te ondersteunen moet u een nieuwe INVITE of een update van IPGW verzenden; dit wordt momenteel echter niet ondersteund . Daarom wordt flow-round met DO-EO-oproepen niet ondersteund. Als er een dergelijk "call-flow"-vereiste van marketing bestaat, zal de steun in aanmerking worden genomen. Het Cisco bug SIP SIP SDO-EO: De vraag faalt in Flow rondom modus voor Call hold & Resume, wordt gemarkeerd als een verbetering voor overweging in de toekomst.
Gerelateerde informatie
- Ondersteuning van multicast muziek-on-Hold op Cisco UBE
- CallManager muziek op Hold Frequent gestelde vragen
- Technische ondersteuning en documentatie – Cisco Systems
[1] Dit kan verwarrend zijn- Hoe kunt u een ander gesprek voeren in een dialoog? In SIP verwijst de dialoog naar de 3-pinstel <To tag, Van tag en Call-ID>. Deze 3-trommel blijft hetzelfde tijdens de opnamefase.
[2] DO - vertraagd aanbod.
[3] Inter-cluster romp
[4] Vanaf CUCM 8.5.
[5] Codering werkt voor MoH in Cisco IOS versies 15.3T en hoger.
[6] Aanbod vertraagd
[7] Cisco Unified Communications Manager-functies en -servicesgids, release 8.6(1)
[8] Dit zijn instellingen in het SIP-profiel dat wordt gebruikt om de SIP-romp te configureren.
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)