Experiencing One Way Audio When Connecting via SIP
81882
Created On 04/27/19 14:35 PM - Last Modified 05/15/19 21:58 PM
Symptom
Experiencing one-way audio when connecting via SIP (Session Initiation Protocol).
Environment
PAN-OS
Cause
SIP (Session Initiation Protocol) allows two endpoints to establish media sessions with each other. This is an application layer signaling protocol.
The main signaling functions of the protocol are as follows:
– Location of an end point.
– Contacting an end point to determine willingness to establish a session.
– Exchange of media information to allow a session to be established.
– Modification of existing media sessions.
– Teardown of existing media sessions.
An SIP at every hop is referred to as a call leg.
The SIP phone is registered with the internal server (CUCM, CME) and gets all the configuration related to the extension number, which is supported Codecs. Every site will be having a T1 and E1 ISDN connection from the SIP provider that can connect to the public telephony network. The common setup looks like below:
Phone user1===>(Registered)===>CUCM===>CUBE===>(Palo Alto Networks Firewall)===>ISP SBCs===>Dst VOIP gateway===>VOIP server===>user2
The caller initiates the call through an INVITE message, and the proxy server is responsible to initiate a connection on behalf of the caller (user1).
Here is the SIP call flow:
INVITE Message: INVITE messages are generated by the caller, which is sent to the server. The Proxy server is responsible to initiating a connection. The INVITE header has the caller and the calling party information, including the unique call IDs. Here are two new terminologies for clarification: Early Handoff and Delayed Handoff.
Early Handoff: In the above image, you can see the INVITE message without SDP (Session Description Protocol) payload. The most common setup is to initiate an SDP payload with the INVITE message. When you see the SDP payload within the INVITE message, that is considered an Early Handoff.
The SDP contains the information of the media type and media used between the two endpoints. The SDP also contains the information of the media IP address, RTP port number, codec type (G.711, G.729 ) information and many more.
Delayed Handoff: When you do not see the SDP payload in the INVITE message, that setup is a Delayed Handoff. Then the called party has to first send its own media information for the caller to negotiate.
An example of an INVITE message with SDP payload is below:
INVITE sip:calling_to@10.101.5.120 SIP/2.0
From: “Called_id” <sip:Caller@10.101.6.120>;tag=35b8d8a74ca0f4e34e0adfa7_F10.101.6.120
To: sip:Calling_to@10.101.5.120
Call-ID: f_169eac17a017b0a4e0adfa8_I@10.101.6.120
CSeq: 15 INVITE
Via: SIP/2.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
Supported: replaces
SDP:
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/8000/1
SDP Payload:
c=IN IP4 10.101.6.120 ===> IP address to be used by the calling party for exchange of the audio packets
m=audio 5000 RTP/AVP 0 8 18 4 120 ======> RTP port number to be user by the calling party.
SIP ALG:
ALG stands for Application Layer Gateway, which is responsible to do NAT on the Layer 7 packet (Invite and SDP). Palo Alto Networks firewalls are capable of performing ALG on the SIP packets, and you do not have to do any additional configuration to enable this feature. As soon as the firewall identifies the traffic as SIP application, it will invoke the ALG decoder and perform a Layer 7 NAT. Firewalls like Palo Alto Networks firewalls will take the media information and open up a pinhole or "Predict Session" to allow the media packets.
Resolution
ISSUE:
An issue may arise when you disable this feature on the firewall by going into the firewall (Objects > Application > SIP > ALG) and configure an application override for the SIP traffic. After doing the app override the firewall will loose the Layer 7 visibility and will not be able to perform Layer 7 NAT.
Why it is important to enable ALG?
Every phone is assigned an RFC 1918 Private IP address. When the phone initiates the SDP packets RTP media IP address it will also be a private IP address. If the phone is not a NAT aware device or there is no ALG performing device in the network, then the layer 7 packet will be having the private IP address when it reaches to the destination phone. After all the signaling done and they try to send the actual RTP/Audio packets the destination will send it to a private IP address which it received in the SDP packet and will not be a routed IP address in public internet. That is the main reason we will have a one way audio in the VOIP calls.
Where you do not need ALG?
If your phone is a NAT aware phone or you have some other device in the middle that is ALG an enabled device. This can also be seen when you are doing ALG in the network and the firewall is also doing ALG, which causes the packets to be a double NAT. This could create some issues like delay and dropped calls among other issues.
Additional Information
To see if the firewall is doing ALG, you can go to Object > Application > SIP > ALG.
It should be set to enable "yes."
Take packet captures between the phone and the ISP SBC (Session Boarder Controller). Always remember to put the filters as below:
NOTE: Customers should be aware about the IP address of the SBC's provided by the ISP. There should be a security policy which should allow the communication to those 2 IP addresses.
Index 1:
Src IP – Calling phones IP address
Dst IP – SBC ip address provided by the ISP ( usually it will be 2 different IP address for the failover/load sharing )
Index 2:
Vice Versa
Index 3:
src IP : Calling phones IP address
Dst IP : 0.0.0.0
Index 4:
Src IP : 0.0.0.0
Dst IP: Calling phone ip address.
After taking the PCAPs, you have to check the transmit stage PCAPs, which should have all the SIP/SDP heard IP changed to the NAT IP address. It is also important to take the caller name, receiver's name, and extension number to verify the SIP header in the PCAPs.
Below is a command you can run to verify if the firewall is doing ALG.
> show appinfo2ip
In case of any issue with the call drop, one way audio, you need to collect flow basic, appid basic, ctd basic, and PCAPs at the minimum.