Faire l’expérience de l’audio à sens unique lors de la connexion via SIP
82028
Created On 04/27/19 14:35 PM - Last Modified 03/26/21 17:40 PM
Symptom
Faire l’expérience de l’audio à sens unique lors de la connexion via SIP (Protocole d’initiation de session).
Environment
PAN-OS
Cause
SIP (Protocole d’initiation à la session) permet à deux points de terminaison d’établir des sessions médiatiques entre eux. Il s’agit d’un protocole de signalisation de couche d’application.
Les principales fonctions de signalisation du protocole sont les suivantes :
– Emplacement d’un point final.
– Contacter un point final pour déterminer la volonté d’établir une session.
– Échange d’informations sur les médias pour permettre la création d’une session.
– Modification des sessions médias existantes.
– Démontage des sessions médiatiques existantes.
Un SIP à chaque saut est appelé une jambe d’appel.
Le SIP téléphone est enregistré avec le serveur interne ( , ) et obtient toute la configuration liée au CUCM numéro CME d’extension, qui est pris en charge Codecs. Chaque site aura une connexion T1 et E1 ISDN du fournisseur qui peut se connecter au réseau de téléphonie SIP publique. La configuration commune ressemble à ci-dessous:
Utilisateur du téléphone1===> (Enregistré)===> CUCM ===> CUBE ===>(Palo Alto Networks Firewall )====> ISP SBCs===>Dst VOIP gateway====> VOIP server====>user2
L’appelant lance l’appel par le biais d’un INVITE message, et le serveur proxy est responsable d’initier une connexion au nom de l’appelant (utilisateur1).
Voici le flux SIP d’appels :
INVITEMessage : les messages sont INVITE générés par l’appelant, qui est envoyé au serveur. Le serveur Proxy est responsable de l’introduction d’une connexion. INVITEL’en-tête a l’appelant et les informations de la partie appelante, y compris les pièces d’identité d’appel uniques. Voici deux nouvelles terminologies à clarifier : le transfert précoce et le transfert retardé.
Transfert précoce : Dans l’image ci-dessus, vous pouvez voir INVITE le message sans charge utile SDP (Protocole de description de session). La configuration la plus courante est d’initier SDP une charge utile avec le INVITE message. Lorsque vous voyez la SDP charge utile dans le INVITE message, cela est considéré comme un transfert précoce.
Le SDP contient les informations du type de médias et des médias utilisés entre les deux critères d’évaluation. Le SDP contient également les informations de l’adresse IP multimédia, numéro de RTP port, type codec ( G .711, G .729 ) informations et bien plus encore.
Transfert retardé : lorsque vous ne voyez pas la SDP charge utile dans le INVITE message, cette configuration est un transfert retardé. Ensuite, la partie appelée doit d’abord envoyer ses propres informations médiatiques pour que l’appelant négocie.
Un exemple INVITE d’un message avec SDP charge utile est
INVITE ci-dessous: siroter:calling_to@10.101.5.120 SIP /2.0
De: « Called_id » <sip:Caller@10.101.6.120>; tag =35b8d8a74ca0f4e34e0adfa7_F10.101.6.120
To: sip:Calling_to@10.101.5.120
Appel- : ID f_169eac17a017b0a4e0adfa8_I@10.101.6.120
CSeq: 15 Via: /2.2.101.6.120 CSeq: 15 INVITE
Via: SIP /2.0 0/ UDP 10.101.6.120;branch=z9hG4bKf_169eac12baa17054e0adfb3_I
Content-Length: 306
Max-Forwards: 70
Contact: sip:Caller@10.101.6.120;transport=udp
Content-Type: application/sdp
User-Agent: Avaya SIP Softphone
Pris en charge:
SDPremplace:
v=0
o=sip:caller@10.101.6.120 1 16 IN IP4 10.101.6.120
s=sip:caller@10.101.6.120
c= IN IP4 10.101.6.120
t=0 0
m=audio 5000 RTP / AVP 0 8 18 4 120
a=rtpmap:0 PCMU /8000/1
a=rtpmap:8 PCMA /8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000/1
a=rtpmap:120 telephone-event/800 0/1
SDP Charge utile :
c= IN IP4 10.101.6.120 ====> adresse à utiliser par la IP partie appelante pour l’échange des paquets audio
m=audio 5000 RTP / AVP 0 8 18 4 120 ======> numéro de port pour être utilisateur par la RTP partie appelante.
SIP ALG:
ALG signifie Passerelle de couche d’application, ce qui est responsable de faire sur le paquet de NAT couche 7 (Inviter et SDP ).</sip:Caller@10.101.6.120> Les pare-feu Palo Alto Networks sont capables ALG d’effectuer sur SIP les paquets, et vous n’avez pas à faire de configuration supplémentaire pour activer cette fonctionnalité. Dès que le trafic firewall identifie le trafic comme SIP application, il invoque ALG le décodeur et effectue une couche 7 NAT . Les pare-feu comme les pare-feu Palo Alto Networks prennent les informations des médias et ouvrent un sténopé ou une « session de prédiction » pour autoriser les paquets multimédias.
Resolution
ISSUE:
Un problème peut survenir lorsque vous désactivez cette fonctionnalité sur le firewall en allant dans le ( firewall Objets > Application > > ) SIP et ALG configurer une substitution d’application pour le SIP trafic. Après avoir fait l’application remplacer le firewall perdra la visibilité couche 7 et ne sera pas en mesure d’effectuer la couche 7 NAT .
Pourquoi est-il important d’activer ALG ?
Chaque téléphone se voit attribuer RFC une adresse privée de 1918. IP Lorsque le téléphone initie SDP l’adresse RTP multimédia IP des paquets, il s’agit également d’une IP adresse privée. Si le téléphone n’est pas un NAT appareil conscient ou s’il n’y a ALG pas d’appareil performant dans le réseau, alors le paquet de couche 7 aura IP l’adresse privée lorsqu’il atteindra le téléphone de destination. Après toute la signalisation effectuée et ils essaient d’envoyer les RTP paquets réels / Audio la destination l’enverra à une adresse IP privée qu’il a reçu dans le paquet et ne sera pas une adresse SDP IP acheminé dans l’Internet public. C’est la principale raison pour laquelle nous aurons un audio à sens unique dans les VOIP appels.
Où vous n’avez pas besoin ALG ?
Si votre téléphone est un NAT téléphone conscient ou si vous avez un autre appareil au milieu qui est un appareil ALG activé. Cela peut également être vu lorsque vous faites ALG dans le réseau et le fait aussi , ce qui provoque les firewall ALG paquets d’être un double NAT . Cela pourrait créer certains problèmes comme le retard et l’abandon des appels entre autres questions.
Additional Information
Pour voir si le firewall ALG fait, vous pouvez aller à Object > Application > SIP > ALG .
Il devrait être défini pour permettre « oui ».
Prenez des captures de paquets entre le téléphone et ISP SBC le (Contrôleur boarder session). N’oubliez pas de mettre les filtres comme
NOTEci-dessous: : Les clients doivent être conscients IP de SBC l’adresse des 's fournis par le ISP . Il devrait y avoir une policy sécurité qui devrait permettre la communication à ces 2 IP adresses.
Index 1:
Src IP – Appel téléphone adresse IP
Dst – adresse IP fournie IP par le ( habituellement ce sera SBC ISP 2 adresse différente pour le IP failover / partage de charge )
Index 2:
Vice Versa
Index 3:
src IP : Appeler les téléphones adresse IP
IP Dst: 0.0.0.0
Index 4:
IP Src: 0.0.0.0
Dst : Appel ip IP adresse.
Après avoir pris les PCAPs, vous devez vérifier l’étape de transmission PCAPs, qui devrait avoir tous SIP les / entendu changé à SDP IP NAT IP l’adresse. Il est également important de prendre le nom de l’appelant, le nom du récepteur et le numéro d’extension pour vérifier SIP l’en-tête dans les PCAPs.
Voici une commande que vous pouvez exécuter pour vérifier si le firewall fait ALG .
> afficher appinfo2ip En cas de problème avec la
baisse d’appel, audio dans un sens, vous devez collecter le flux de base, appid de base, ctd de base, et PCAPs au minimum.