NAT in VoIP
Inhoud
Inleiding
Dit document beschrijft het NAT-gedrag (Network Address Translation) bij routers die werken als CUBE (Cisco Unified Border Element), CME of CUCME (Cisco Unified Communication Manager Express), Gateways en CUSP (Cisco Unified SIP Proxy).
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- SIP (Session Initiation Protocol)
- Voice over IP (internetprotocol)
- Routeringsprotocollen
Gebruikte componenten
De informatie in dit document is gebaseerd op
- Alle IOS-versies 12.4T en hoger.
- Elke CME-versie
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.
Achtergrondinformatie
Network Address Translation is een veelgebruikte techniek om IP-adressen te vertalen op pakketten die tussen netwerken stromen met behulp van verschillende adresruimten. Het doel van dit document is niet om NAT te herzien. In plaats daarvan is dit document bedoeld om een uitgebreid overzicht te geven van NAT zoals het wordt gebruikt in de VoIP-netwerken van Cisco. Bovendien is het bereik beperkt tot componenten die deel uitmaken van de MS-Voice-technologie.
- NAT vervangt in principe het IP-adres binnen pakketten met een ander IP-adres
- Meerdere hosts in een privé-subnet kunnen één openbaar IP-adres delen (d.w.z. eruit zien als) om toegang te krijgen tot internet.
- NAT-configuraties wijzigen doorgaans alleen het IP-adres van interne hosts
- NAT is bidirectioneel - Als A op de interne interface naar B wordt vertaald, wordt B naar de externe interface vertaald naar A!
- RFC1631
Afbeelding 1
Figuur 2 toont de topologie waarnaar wordt verwezen in de illustraties die volgen.
Afbeelding 2
Deze woordenlijst is fundamenteel om NAT te begrijpen en te beschrijven
- Binnen het lokale adres: het IP-adres dat is toegewezen aan een host in het interne netwerk. Meestal is het adres afkomstig van een privéadresruimte.
- Binnen een globaal adres: een routeerbaar IP-adres dat door de NIC of serviceprovider is toegewezen en dat een of meer interne lokale IP-adressen naar de buitenwereld vertegenwoordigt.
- Buiten het lokale adres: het IP-adres van een externe host zoals dat in het netwerk wordt weergegeven. Niet noodzakelijk een legitiem adres, het wordt toegewezen vanuit een adresruimte die aan de binnenkant kan worden gerouteerd.
- Buiten globaal adres: het IP-adres dat door de eigenaar van de host aan een host op het externe netwerk is toegewezen. Het adres wordt toegewezen vanaf een wereldwijd routeerbaar adres of netwerkruimte.
Statische NAT
Dit is de eenvoudigste vorm van NAT, waarbij in elk binnenadres statisch wordt vertaald naar een buitenadres (en vice versa).
Afbeelding 3
De CLI-configuratie voor de bovenstaande vertaling is als volgt
Ethernet-interface0/0
IP-adres 10.1.1.3 255.255.255.0
IP NAT Inside
Ja!
Seriële interface0/0
IP-adres 200.1.1.251 255.255.255.252
ip nat buiten <-- Vereist![2]
IP NAT Inside Source Static 10.1.1.2 200.1.1.2
IP NAT Inside Source Static 10.1.1.1 200.1.1.1
Dynamische NAT
In dynamische NAT wordt elke inside host toegewezen aan een adres uit een pool van adressen.
- Hiermee wordt een IP-adres toegewezen vanuit een pool met globale adressen.
- Als een nieuw pakket van nog een andere host binnenkomt en het een NAT-vermelding nodig heeft, maar alle gepoolde IP-adressen in gebruik zijn, gooit de router het pakket gewoon weg.
- In wezen moet de pool van interne globale adressen zo groot zijn als het maximale aantal gelijktijdige hosts dat tegelijkertijd gebruik moet maken van internet
De volgende CLI illustreert het configureren van dynamische NAT
NAT-overbelasting (PAT)
Wanneer de pool (van IP-adressen) kleiner is dan de set adressen die moet worden vertaald, komt deze functie van pas.
- Verschillende interne adressen NATed slechts één of enkele externe adressen
- PAT (Port Address Translation) gebruikt unieke bronpoortnummers op het Inside Global IP-adres om onderscheid te maken tussen vertalingen. Omdat het poortnummer in 16 bits is gecodeerd, kan het totale aantal in theorie oplopen tot 65.536 per IP-adres. PAT zal proberen de oorspronkelijke bronpoort te behouden, als deze bronpoort al is toegewezen, zal PAT proberen het eerste beschikbare poortnummer te vinden
- NAT-overbelasting kan meer dan 65.000 poorten gebruiken, waardoor het goed kan schalen zonder veel geregistreerde IP-adressen nodig te hebben - in veel gevallen hoeft slechts één extern wereldwijd IP-adres.
Figuur 4 illustreert PAT.
Afbeelding 4
Opties voor NAT Command
Cisco NAT-implementatie is zeer veelzijdig met een groot aantal opties. Een paar worden hieronder vermeld, maar raadpleeg http://www.cisco.com/en/US/partner/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html voor meer informatie over de volledige lijst met verbeteringen.
- Statische vertalingen met poorten – Inkomende pakketten die zijn gericht op een specifieke poort (bijv. poort 25, voor SMTP-server) die naar een specifieke server is verzonden.
- Ondersteuning voor routekaarten - Flexibiliteit in het configureren van filters/ACL's
- Flexibelere poolconfiguraties - om discontinue adresbereiken mogelijk te maken.
- Behoud van hostnummers - Vertaal het gedeelte "netwerk" en behoud het gedeelte "host".
NAT-pinhole
Een pinhole in NAT-taal verwijst naar de toewijzing tussen de <host IP, poort> en <global address, global port> tuples. Hiermee kan het NAT-apparaat het bestemmingspoortnummer (dat de wereldwijde poort zou zijn) van inkomende berichten gebruiken om de bestemming terug te koppelen naar het host-IP en de poort die de sessie heeft gestart. Het is belangrijk op te merken dat pinholes time-out na een periode van niet-gebruik en het openbare adres wordt teruggestuurd naar de NAT-pool.
NAT in VoIP
Dus, wat zijn de problemen en zorgen met NAT in VoIP-netwerken? Nou, herinner je dat NAT die we tot nu toe hebben besproken (nauw aangeduid als basis NAT) vertaalt alleen het IP-adres in de IP-pakket header en herberekent de checksum, natuurlijk, maar VoIP-signalering dragen adressen ingebed in het lichaam van de signalering berichten. Met andere woorden, op laag 5
Figuur 5 illustreert het effect van het niet-vertaald laten van de ingesloten IP-adressen. De oproepsignalering is voltooid, maar de SIP-proxy bij de serviceprovider slaagt er niet in om mediapakketten (RTP) te routeren naar het mediumadres dat door de oproepagent is verzonden!
Afbeelding 5
Een ander voorbeeld is het gebruik van Contact: veld in SDP door het SIP-eindpunt om het adres te communiceren waarop het eindpunt signaleringsberichten voor nieuwe verzoeken zou willen ontvangen.
Deze problemen worden aangepakt door een functie genaamd Application Layer Gateway (ALG).
ALG
Een ALG begrijpt het protocol dat wordt gebruikt door de specifieke toepassingen die het ondersteunt (bijv. SIP) en doet protocolpakketinspectie en "fixup" van verkeer erdoorheen. Voor een goede beschrijving van hoe de verschillende velden zijn opgemaakt voor SIP-oproepsignalering, raadpleegt u http://www.voip-info.org/wiki/view/Routers+SIP+ALG.
Op Cisco-routers is ondersteuning voor ALG SIP standaard ingeschakeld op de standaard TCP-poort 5060. Het is mogelijk om ALG te configureren om niet-standaard poorten voor SIP-signalering te ondersteunen. Zie http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-tcp-sip-alg.html.
Gateways
Aangezien gateways per definitie geen ip-to-ip-apparaten zijn, is NAT niet van toepassing.
CME
In dit gedeelte van het document worden scenario's met CME besproken om te begrijpen waarom NAT moet worden gebruikt.
Scenario 1. Lokale telefoons
Scenario 2. Telefoons op afstand (met openbare IP-adressen)
Scenario 3. telewerker op afstand
plaatselijk
In dit scenario (Afbeelding 6) zijn de twee telefoons die betrokken zijn bij het gesprek magere telefoons met privé-IP-adressen.
Afbeelding 6
Daarom is NAT in dit geval niet van toepassing of vereist.
Lokaal naar extern
In dit scenario (Afbeelding 7) plaatst CME zichzelf in de RTP-stroom, zodat RTP van de telefoons op de CME wordt beëindigd. CME zal de streams opnieuw opstarten naar de andere telefoon. Aangezien CME zowel binnen als buiten het (privé)netwerk zit en zijn adres naar binnen en buiten (openbaar) naar buiten stuurt, is NAT ook hier niet vereist.
Merk echter op dat de UDP / TCP-poorten (zowel signalering als RTP) open moeten zijn tussen externe IP-telefoon en CME-bron IP-adres. Dit betekent dat de firewalls of andere filterapparaten zijn geconfigureerd om de betreffende poorten toe te staan.
Afbeelding 7
telewerker op afstand
Dit verwijst naar IP-telefoons die via een WAN verbinding maken met CME om telewerkers te ondersteunen die kantoren hebben die ver van de CME-router zijn verwijderd. De meest voorkomende ontwerpen zijn die waarbij telefoons met routeerbare IP-adressen en telefoons met privé-IP-adressen.
Externe telefoons met openbare (lees: routeerbare) IP-adressen
Als beide bij het gesprek betrokken telefoons zijn geconfigureerd met openbare, routeerbare IP-adressen, kunnen media rechtstreeks tussen de telefoons stromen (Afbeelding 8). Daarom is NAT ook weer niet nodig!
Afbeelding 8
Telefoons op afstand met privé-IP-adres
In dit scenario wordt het gesprek gesignaleerd tussen magere telefoons die zijn geconfigureerd met privé-IP-adressen. De routers van het thuiskantoor (SOHO) zijn over het algemeen niet "SCCP-bewust", d.w.z. niet in staat om de IP-adressen te vertalen die zijn ingesloten in de SCCP-berichten. Dit betekent dat, na voltooiing van de oproepconfiguratie, de telefoons eindigen met elkaars privé-IP-adres. Aangezien beide telefoons privé zijn, zal CME het gesprek tussen hen zodanig signaleren dat de audio rechtstreeks tussen de telefoons stroomt. Dit zal echter resulteren in eenrichtings- of eenrichtingsaudio (aangezien privé-IP-adressen per definitie niet kunnen worden gerouteerd naar op internet!), tenzij een van de volgende oplossingen wordt geïmplementeerd-
· Statische routes configureren op de SOHO-routers
· een IPsec VPN-verbinding tot stand brengen met de telefoons
Een betere manier om dit op te lossen zou zijn om "mtp" te configureren. De opdracht mtp zorgt ervoor dat media (RTP)-pakketten van externe telefoons door de CME-router worden verzonden (Afbeelding 9).
Afbeelding 9
De "mtp" -oplossing is beter vanwege complicaties bij het openen van firewallpoorten. De mediapakketten die over een WAN stromen, kunnen worden geblokkeerd door een firewall. Dit betekent dat u poorten op de firewall moet openen, maar welke? Met CME die de audio doorstuurt, kunnen firewalls eenvoudig worden geconfigureerd om de RTP-pakketten te passeren. De CME-router gebruikt een specifieke UDP-poort (2000!) voor mediapakketten. Dus door alleen pakketten van en naar poort 2000 toe te staan, kan AL het RTP-verkeer worden doorgegeven.
Afbeelding 10 illustreert hoe u mtp configureert.
Telefoon 1
MAC 1111,2222,3333
Type 7965
MTP
Knop 1:1
Afbeelding 10
Het is niet allemaal geweldig met MTP. Er zijn situaties waarin MTP niet wenselijk is
- MTP is niet mild voor CPU-gebruik
- Multicast MOH kan over het algemeen niet worden doorgestuurd via een WAN - De Multicast MOH-functie controleert of MTP is ingeschakeld voor een telefoon en als dit het geval is, verzendt MOH niet naar die telefoon.
Als u dus een WAN-configuratie hebt die multicastpakketten kan doorsturen en u kunt RTP-pakketten toestaan via uw firewall, kunt u besluiten om MTP niet te gebruiken.
Externe SIP-telefoons
Merk op dat SIP-telefoons niet werden genoemd in de bovenstaande scenario's. Dit komt door het feit dat als een van de telefoons een SIP-telefoon is, CME zichzelf in het audiopad plaatst. Dit wordt dan het eerder beschreven scenario van local-to-remote, waarbij NAT niet vereist is.
KUBUS
De CUBE voert inherent NAT- en PAT-functies uit wanneer alle sessies worden beëindigd en opnieuw worden gestart. De CUBE vervangt zijn eigen adres voor het adres van elk eindpunt waarmee wordt gecommuniceerd, waardoor het adres van dat eindpunt effectief wordt verborgen (vertaald).
NAT is dus niet vereist met de CUBE-functie. Er is een VoIP-servicescenario waarin NAT vereist is op de CUBE, zoals beschreven in de volgende sectie.
Gehoste NAT Traversal
Een korte achtergrond van de Hosted telefonie dienst zal helpen begrijpen van de reden voor deze functie.
Gehoste telefoniedienst is een nieuwe vorm van VoIP-dienst waarbij de meeste apparatuur zich op de locatie van de serviceprovider bevindt. Ze werken met de home gateways (HGW), die alleen basis NAT implementeren (dat wil zeggen NAT op L3 / L4). Verizon installeert bijvoorbeeld de Optical Network Terminal (ONT), die FiOS-diensten thuis levert; spraakoproepen worden gesignaleerd met behulp van een SIP-proces dat in het ONT is ingebouwd. De SIP-signalering wordt via het private IP-netwerk van Verizon doorgegeven aan nieuwe soft switches, die de service en controle bieden om spraakcommunicatie tot stand te brengen aan andere klanten van FiOS Digital Voice of aan klanten van traditionele telefoons.
Tot de belangrijkste vereisten van de aanbieder voor de gehoste telefoniedienst behoren onder meer:
- Remote NAT traversal: de mogelijkheid om Class 5-services te leveren aan eindpunten met behulp van NAT (die alleen NAT-laag 3 kan uitvoeren!) en firewallapparaten (door op afstand "ALG" te doen!)
- Co-media-ondersteuning: de mogelijkheid om media te verzenden tussen apparaten die zich op dezelfde locatie bevinden, waar het niet zinvol is om de media terug te leiden naar het IP-netwerk
- Geen extra apparatuur, waardoor het niet nodig is om een CPE toe te voegen.
Welke mogelijkheden bestaan er om een dergelijke dienst te implementeren?
- Vervang de HGW door een dure ALG,
- Gebruik een sessiegrenscontroller (SBC) om de ingesloten SIP-headers voor pakketten aan te passen. Dit omvat een door het netwerk gehost, carrier-grade product dat SIP ondersteunt in een zeer veilige, fouttolerante configuratie. Deze oplossing wordt NAT SBC genoemd.
De NAT SBC-optie voldoet aan de hierboven vermelde vereisten van de provider.
NAT SBC
De NAT SBC werkt als volgt (figuur 11)
- Access Router vertaalt alleen het L3/L4 IP-adres
- IP-adres in het SIP-bericht niet vertaald
- SBC NAT onderschept en vertaalt het ingesloten IP-adres. Op het moment dat de SBC SIP-pakketten ziet die bestemd zijn voor 200.200.200.10, trapt het in de nat-sbc-code.
- Media worden niet vertaald en gaan direct tussen de telefoons[5]
Afbeelding 11
Ontwerpnotities
- Het IP-adres 200.200.200.10 (figuur 12) is niet toegewezen aan een interface op de NAT SBC. Het is geconfigureerd als het adres van de "proxy" waarnaar SIP Phone A en SIP Phone B signaleringsberichten verzenden.
- Thuisapparaten vertalen bepaalde velden met alleen SIP/SDP-adressen niet (bijv. Call-Id: ,O= , Waarschuwing: headers & branch= parameter. maddr= en received= parameters werden alleen in bepaalde scenario's verwerkt.). Deze velden worden afgehandeld door de NAT SBC, met uitzondering van de proxy-autorisatie en autorisatie vertaling, omdat deze de authenticatie zal breken.
- Als de thuisapparaten zijn geconfigureerd om PAT uit te voeren, moeten de gebruikersagenten (telefoons en proxy) symmetrische signalering[6] en symmetrische en vroege media ondersteunen. U moet de override-poort op de NAT SBC-router configureren.
- Bij gebrek aan ondersteuning voor symmetrische signalering en symmetrische en vroege media, moeten de intermediaire routers zonder PAT worden geconfigureerd en moet het override-adres in de NAT SBC worden geconfigureerd.
Configuratie
Voorbeeldconfiguratie voor een typische NAT SBC volgt.
IP NAT SIP-SBC
Proxy 200.200.200.10 5060 15.3.33.22 5060 Protocol UDP
call-id-pool call-id-pool
Sessietime-out 300
omloopmodus
override-poort
Ja!
IP NAT Pool SBC1 15.3.33.61 15.3.33.69 Netmasker 255.255.0.0
IP NAT Pool SBC2 15.3.33.91 15.3.33.99 Netmasker 255.255.0.0
IP NAT Pool Call-ID-Pool 1.1.1.1 1.1.255.254 Netmask 255.255.0.0
IP NAT-pool Buiten-pool 200.200.200.100 200.200.200.200 Netmasker 255.255.255.0
IP NAT Inside Source List 1 Pool SBC1 Overload
IP NAT binnen bronlijst 2 pool SBC2
IP NAT buiten bronlijst 3 pool buiten pool add-route
IP NAT Inside Source List 4-pool Call-ID-pool
Ja!
Toegangslijst 1 vergunning 10.1.1.0 0.0.0.255
Toegangslijst 1 vergunning 171.1.1.0 0.0.0.255
Toegangslijst 2 vergunning 20.1.1.0 0.0.0.255
Toegangslijst 2 vergunning 172.1.1.0 0.0.0.255
Toegangslijst 3 vergunning 15.4.0.0 0.0.255.255
Toegangslijst 3 vergunning 15.5.0.0 0.0.255.255
Toegangslijst 4 vergunning 10.1.0.0 0.0.255.255
Toegangslijst 4 vergunning 20.1.0.0 0.0.255.255
Oproepstroom met SBC NAT
Figuur 13 en figuur 14 illustreren de oproepstroom wat betreft de vertalingen. De volgende punten dienen te worden opgemerkt-
- Bij aanmelding noteert de soft switch de twee telefoons als
-- SIP Phone A – 15.3.33.62 2001
-- SIP Phone B – 15.3.33.62 2002
- In deze gespreksstroom laat SBC NAT het media-IP-adres effectief niet-vertaald.
Afbeelding 13
Afbeelding 14
SIP-registratie
In eerdere versies (van SBC NAT) moesten SIP-eindpunten keep-alive-pakketten verzenden om de pinhole van de SIP-registratie open te houden (om out->in het verkeer te laten stromen, bijvoorbeeld inkomende oproepen). keep-alive-pakketten kunnen elk SIP-pakket zijn dat door het eindpunt of de registrar (soft switch) wordt verzonden. Recente versies voorkomen de noodzaak hiervan, waarbij de NAT-SBC zelf (in tegenstelling tot soft switches) de eindpunten dwingt om zich regelmatig opnieuw te registreren om de pinholes open te houden.
CUSP
CUSP heeft de notie van een logisch netwerk, dat verwijst naar een verzameling lokale interfaces die op dezelfde manier worden behandeld voor routeringsdoeleinden (bijvoorbeeld interface, poort, transport voor luisteren). Wanneer u een logisch netwerk configureert op CUSP, kunt u het configureren om NAT te gebruiken. Na de configuratie wordt SIP ALG automatisch ingeschakeld. Dit is handig bij bepaalde logische netwerken.
Probleemoplossing
Symptomen
Een voor de hand liggend symptoom kan zijn dat een oproep in één of beide richtingen mislukt. Minder voor de hand liggende symptomen kunnen zijn,
- Audio in één richting
- Eenrichtingsaudio bij overdracht
- No-way audio
- SIP-registratie verliezen
Opdrachten voor weergeven en foutopsporing
- DEB IP NAT [SIP | Skinny]
- Statistieken IP NAT weergeven
- IP NAT-vertalingen weergeven
Dingen om te controleren
- Zorg ervoor dat de configuratie de ip nat binnen of ip nat buiten interface subopdracht bevat. Deze opdrachten maken NAT op de interfaces mogelijk en de aanduiding binnen/buiten is belangrijk.
- Voor statische NAT moet u ervoor zorgen dat de statische opdracht ip nat source eerst het lokale adres vermeldt en vervolgens het algemene IP-adres binnen.
- Zorg er voor dynamische NAT voor dat de ACL is geconfigureerd om overeen te komen met pakketten die zijn verzonden door de inside host en overeenkomen met de pakketten van die host, voordat een NAT-vertaling heeft plaatsgevonden. Als bijvoorbeeld een lokaal adres van 10.1.1.1 moet worden vertaald naar 200.1.1.1, moet u ervoor zorgen dat het ACL overeenkomt met het bronadres 10.1.1.1, niet met 200.1.1.1.
- Voor dynamische NAT zonder PAT moet u ervoor zorgen dat de pool voldoende IP-adressen heeft. Symptomen van het niet hebben van voldoende adressen zijn onder meer een groeiende waarde in de tweede missenteller in de show ip nat-statistieken-opdrachtuitvoer, evenals het zien van alle adressen in het bereik dat is gedefinieerd in de NAT-pool in de lijst met dynamische vertalingen.
- Voor PAT is het gemakkelijk om te vergeten om de optie overbelasting toe te voegen aan de opdracht ip nat inside source list. Zonder dat werkt NAT, maar PAT niet, wat vaak resulteert in pakketten van gebruikers die niet worden vertaald en hosts die niet in staat zijn om naar het internet te gaan.
- Misschien is NAT correct geconfigureerd, maar er bestaat een ACL op een van de interfaces, waarbij de pakketten worden weggegooid. Merk op dat IOS ACL's verwerkt vóór NAT voor pakketten die een interface binnenkomen en na het vertalen van de adressen voor pakketten die een interface verlaten.
- Vergeet niet om "ip nat outside" te configureren op de interface met het WAN (zelfs als u geen extern adres vertaalt)!
- Zodra NAT is geconfigureerd, wordt er niets weergegeven in de vertalingen van show ip nat. Ping een keer en controleer het dan opnieuw.
- Pak draadhaaisporen op binnen- en buiteninterfaces van de NAT-SBC
Scenario's
Debug-uitvoer voor een paar scenario's worden hieronder weergegeven. Ze zijn grotendeels voor zichzelf sprekend!
Basis-NAT
Configuratie- en foutopsporingslijnen voor standaard NAT worden hieronder weergegeven.
SIP ALG
Uitvoerlijnen van debug ip nat sip worden weergegeven. In dit geval wordt het ingebedde IP-adres op een uitgaand pakket vertaald.
Referenties
Overzicht:
- http://www.cisco.com/en/US/partner/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html
- Anatomie: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html
- http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml
VoiP en NAT
- https://supportforums.cisco.com/docs/DOC-5406
- http://www.juniper.net/techpubs/software/junos-security/junos-security95/junos-security-swconfig-security/id-60290.html
NAT-functiematrix
- http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080b17919.shtml
- http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a00801af2b9.html
- http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080b17919.shtml
Gehoste NAT-traversal:
NAT SBC
- EDCS-611622
- EDCS-526070
ALG:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/15-0s/iadnat-applvlgw.html
- http://www.voip-info.org/wiki/view/Routers+SIP+ALG
- http://www.commpartners.us/knowledge/attachments/voip-nat.pdf
- http://www.cisco.com/en/US/partner/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-tcp-sip-alg.html
CME
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
23-May-2017
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)