När du ska konfigurera SIP Link krävs en rad olika integrationer. Den här artikeln beskriver felsökningen under integrationen.
Innan du börjar
Kontrollera att du har följande när du ska felsöka SIP Link:
- Paketinspelning för SBC
- Paketinspelning för brandväggen
- Ett verktyg för att visa paketinspelningar
- Åtkomst till SBC-loggarna
Obs! Om du behöver mer hjälp med felsökning kan du kontakta SBC-leverantören eller operatören.
Bekräfta signalanslutningen med SIP Link
Signalering för SIP Link använder TLS (Transport Layer Security). TLS består av ett paket med certifikat som har skapats av offentliga certifikatutfärdare. Du kan kontrollera statusen för TLS-anslutningen på administratörskontrollpanelens målsida för SIP Link.
- Bekräfta att TLS-certifikatet kommer från en av följande certifikatutfärdare:
- DigiCert
- Entrust DataCard
- GlobalSign
- GoDaddy
- Sectigo
- Starta en trevägs TCP-handskakning (Transmission Control Protocol), följt av en TLS-handskakning.
När certifikaten utväxlas skickar Voice ett certifikat följt av SBC-certifikaten.
- När detta sker kan appdata utväxlas mellan Voice och din SBC.
Felsöka samtalskvaliteten
Om du har problem med samtalskvaliteten kan du kontrollera att nätverkslatensen är konsekvent och låg. Samtalskvaliteten är som bäst när Voice-trafiken tar den kortaste vägen mellan Voice och SBC. Ditt mål ska vara en tur-och-retur-latens på högst 100 ms.
Så här testar du nätverkslatens:
- Pinga medieservern för Voice från det externa gränssnittet för SBC.
- Fortsätt vara ansluten till Voice i minst fyra timmar.
- Se till att latensen är konsekvent vid 100 ms eller mindre. Ta inte ett genomsnittligt latensvärde och kontrollera om det förekommer latenstoppar.
- Om latensen inte är 100 ms eller mindre kan du använda traceroute-verktyget för att skriva ut nätverkssökvägen från SBC eller klientdatorn till medieservern för Voice. Vägen ska vara så kort som möjligt, till exempel:
- För datorer använder du > traceroute lens.voice.google.com eller > traceroute 74.125.39.139
- För Chromebooks använder du > tracepath lens.voice.google.com
- För SBC använder du traceroute siplink.telephony.goog eller traceroute lens.voice.google.com
Felsöka vanliga problem med signalanslutningar
Det går inte att upprätta en TCP-session mellan SBC och Voice
Om TCP-sessionen inte upprättas kan det bero på ett problem med brandväggen eller nätverksanslutningen. SBC kan skicka ett SYN-meddelande, men det kommer inget svar.
Så här löser du problemet
- Pinga siplink.telephony.google för att säkerställa att nätverksanslutningen är tillgänglig.
- Aktivera destinationsport 5672 för Voice.
- Kontrollera att DNS fungerar för siplink.telephony.goog.
- Kontrollera att brandväggen tillåter trafik från SBC och att porten siplink.telephony.goog:5672 är öppen.
Det går inte att uppräta en TLS-session mellan SBC och Voice
Så här löser du problemet
- Kontrollera att rotcertifikatet och det mellanliggande certifikat som är kopplat till PCA har laddats upp i keystore som har kopplats till TLS-profilen för SIP Link. När du skapar CSR för SBC-certifieringen ska du följa riktlinjerna i interop-dokumentet för respektive SBC-leverantör.
- Kontrollera att ditt SBC-certifikat följer dessa riktlinjer:
- Nyckelstorlek: 2 048
- RSA- eller ECDSA-kryptering
- Namnet (CN) matchar värdnamnet som har skapats för SIP Link
- Domänen för CN i certifikatet matchar Workspace-domänen
- Ömsesidig autentisering har aktiverats
- Server- och klientautentisering har aktiverats
- Jokerteckencertifikat stöds inte
- Kontrollera att Googles GTSR1-certifiering på pki.goog också har laddats upp till keystore för respektive TLS-profil för SIP Link.
- Kontrollera om certifikatets giltighet från SBC till Google har löpt ut.
Svaret 404 eller 604 Hittades inte under SBC-inbjudan
Om du får svaret 404 eller 604 Hittades inte under inbjudan från SBC har du kanske inte tilldelat Voice SBC-numret.
Så här löser du problemet
- Kontrollera att telefonnumret för SBC har tilldelats en användare, virtuell receptionist eller uppringningsgrupp i Voice.
- Bekräfta att telefonnumret har formatet E. 164 i PAI-rubriken.
Svaret 400 Felaktig begäran under SBC-inbjudan
Om du får svaret 400 Felaktig begäran under inbjudan från SBC använder du kanske inte rätt säkerhetsnyckel.
Så här löser du problemet
- Kontrollera att meddelandet i inbjudan innehåller SIP-rubriken X-Google-Pbx-Trunk-Secret-Key med rätt värde. Den här nyckeln genereras när du konfigurerar SIP Link.
- Bekräfta att telefonnumret har formatet E. 164 i rubriken P-Asserted-Identity.
403 Förbjudet svar från Voice
Felsöka vanliga problem med medieanslutningar
Kontrollera att nätverket uppfyller följande villkor innan du börjar felsöka medieanslutningen:
- Nätverket använder DTLS- (Datagram Transport Layer Security) eller SDES-kryptering (Session Description Protocol Security Description for Media Streams), men inte båda.
- Du använder inte okrypterade SDP-erbjudanden. Samtal som görs på det här sättet avslutas automatiskt.
- MKI- eller Crypto-livslängd måste inaktiveras.
- Om du använder DTLS används ett självsignerat certifikat i SBC. Certifikatet behöver inte vara ett certifikat som har signerats av en certifikatutfärdare.
- Kontrollera att en av de kodekar som stöds har konfigurerats i Voice-profilen för SBC, G711 mulaw (PCMU), G711 alaw (PCMA), Opus eller G722.
- DTMF (Dual tone multi-frequency) förekommer som telefonihändelser.
- Tilldela en dedikerad offentlig IP-adress till det externa SBC-gränssnittet.
- Ställ in käll- och mål-NAT för brandväggen.
Certifikatförhandling misslyckades (DTLS)
Om du får ett varningsmeddelande (Nivå: Allvarligt, Beskrivning: Okänd certifikatutfärdare) är certifikatet som används för DTLS kanske inte certifierat.
DTLS-förhandlingen börjar med en certifikathandskakning mellan medieändpunkterna som anges i SDP-anslutningsfälten för erbjudande och svar. När du har gjort det flödar media mellan SBC och Google Voice via en krypterad anslutning.
Lös problemet genom att se till att certifikatet har ett självsignerat certifikat från SBC. Använd inte certifikat som har signerats av en offentlig certifikatutfärdare eftersom det leder till fragmentering över UDP som orsakar problem.
Klientmeddelande från SBC till Voice utan svar (DTLS)
Du kan få flera Client Hello-meddelanden från SBC till Voice utan svar när du använder DTLS-kryptering.
Så här åtgärdar du problemet
- Kontrollera brandväggsportarna och säkerställ att SBC har dubbelriktat medieflöde till port 19305 eller 26500 i IP-delnätet för Voice-media (74.125.39.0/24).
- För SBC Public IP:mediaport <> 74.125.39.0/24:(19302-19308, 26500). Mer information finns i avsnittet om brandväggsportar för SIP Link.
- IP-adresser för media i Google Voice kan nås via ping och de kan testas på det sättet för tillgänglighet från SBC.
Jag får inget svar för UDP från SBC till Voice
Så här åtgärdar du problemet
- Kontrollera brandväggsportarna och säkerställ att SBC har dubbelriktat medieflöde till port 19305 eller 26500 i IP-delnätet för Voice-media (74.125.39.0/24).
- För SBC Public IP:mediaport <> 74.125.39.0/24:(19302-19308, 26500). Mer information finns i avsnittet om brandväggsportar för SIP Link.
- IP-adresser för media i Google Voice kan nås via ping och de kan testas på det sättet för tillgänglighet från SBC.
- När du utför NAT (Network Address Translation) ska brandväggen inte ändra porten som skickas av SBC. Detta gör att Voice släpper det mediepaket som har skickats från SBC, eftersom källan betraktas som den offentliga IP-adressen för SBC men en annan port än det förhandlade erbjudandet och svaret från SDP.
Dubbelriktat paketflöde, men inget ljud under samtal
Google svarar på inbjudan med 486 (SDES)
Om inbjudan innehåller MKI, vilket inte stöds av SIP Link, inaktiverar du MKI.
Relaterade ämnen
Google, Google Workspace och relaterade märken och logotyper är varumärken som tillhör Google LLC. Alla andra företags- och produktnamn är varumärken som tillhör de företag som de är kopplade till.
