SIP trunk - CUBE - one way audio

Rodrigo Marchina Soares · ‎01-02-2016

Hi guys,

I am having a problem deploying a new SIP trunk to a customer.

The scenery is the following:

PSTN———>GW (CUBE)————>CUCM——-------------->IP PHONE

PSTN = Internet link with SIP trunk

GW (CUBE) = Cisco 2901 router

CUCM = CallManager 8.6

IP Phone = Cisco IP Phone

PS: There is a SonicWall firewall between the PSTN and GW

The problem is: When a call is established from outside to inside, only the outside guy listen the inside guy.

Audio = Outside (PSTN) ---------------> Inside (Customer) = Not OK. The customer can't hear me.

Audio = Outside (PSTN) <--------------- Inside (Customer) = OK. I can hear the customer from outside.

PS: For security reasons, I am hiding the SIP public address:

SIP address: 88.x.x.9 and 88.x.x.10

Signalling:UDP port 5060 egress/ingress to:- 88.x.x.9

Media: All UDP ports between 6000 - 40000 egress/ingress to:- 88.x.x.10

Cisco Router GW 2901 Ip address is 192.168.4.40

CUCM are 192.168.4.32 and 37 (PUB and SUB)

=========================================================

Cisco Router Configuration:

voice service voip

mode border-element license capacity 10

allow-connections sip to sip

allow-connections sip to h323

allow-connections h323 to sip

allow-connections h323 to h323

ip address trusted list

ipv4 88.x.x.9

ipv4 88.x.x.10

ipv4 192.168.4.32

ipv4 192.168.4.37

sip

bind control source-interface g0/0

bind media source-interface g0/0

early-offer forced

header-passing

error-passthru

midcall-signaling passthru

dspfarm profile 1 transcode

codec g711ulaw

codec g711alaw

codec g729ar8

codec g729abr8

codec g729r8

associate application cube

maximum session 10

no shut

dial-peer voice 31 voip

description *** WAN side - Incoming from ITSP ***

session protocol sipv2

incoming called-number .

dtmf-relay rtp-nte

codec g711alaw

voice-class sip rel1xx supported 1xx

dial-peer voice 32 voip

description *** All CUCM 4320-4359 Extensions ***

destination-pattern 43..

session protocol sipv2

session target ipv4:192.168.4.32

voice-class sip bind control source-interface GigabitEthernet0/0

voice-class sip bind media source-interface GigabitEthernet0/0

dtmf-relay h245-alphanumeric

codec g711ulaw

!

dial-peer voice 33 voip

description *** All CUCM 4320-4359 Extensions ***

destination-pattern 43..

session protocol sipv2

session target ipv4:192.168.4.37

voice-class sip bind control source-interface GigabitEthernet0/0

voice-class sip bind media source-interface GigabitEthernet0/0

dtmf-relay h245-alphanumeric

codec g711ulaw

dial-peer voice 36 voip

description ** WAN Side dial-peer Long Distance**

destination-pattern 9T

session protocol sipv2

voice-class sip bind control source gig0/0

voice-class sip bind media source gig0/0

session target ipv4:88.x.x.9

dtmf-relay h245-alphanumeric

codec g711alaw

=================

We are not receiving an ACK from ITSP, as we can see below:

07492991578 is my mobile (called)

0yyyyyy4322 is the calling number. (Customer)

195.x.x.1 is the Customer Public IP address = redirect (NAT) to Cisco GW 2901 = 192.168.4.40

1.- INVITE received from ITSP (ITSP -> CUBE)

016873: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:0yyyyyy4322@195.x.x.1;user=phone SIP/2.0

Max-Forwards: 69

Session-Expires: 3600;refresher=uac

Min-SE: 600

Supported: timer, 100rel

To: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>

From: <sip:07492991578@88.x.x.9>;tag=dztfn5od

P-Asserted-Identity: <sip:07492991578@88.x.x.9;user=phone>

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

CSeq: 1 INVITE

Allow: PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL

Via: SIP/2.0/UDP 88.x.x.9:5060;branch=z9hG4bK85ba699fee73d1559b04acfea3aa828a

Contact: <sip:07492991578@88.x.x.9:5060>

Content-Type: application/sdp

Accept: application/sdp

Content-Length: 210

v=0

o=MSX76 80522071823619324 1 IN IP4 88.x.x.9

s=sip call

c=IN IP4 88.x.x.10

t=0 0

m=audio 26420 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

2.- CUBE replies with a 100 Trying (CUBE -> ITSP)

016934: //12497/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 88.x.x.9:5060;branch=z9hG4bK85ba699fee73d1559b04acfea3aa828a

From: <sip:07492991578@88.x.x.9>;tag=dztfn5od

To: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

CSeq: 1 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-15.5.1.T

Content-Length: 0

3.- CUBE sends INVITE to CUCM (CUBE -> CUCM)

016935: //12498/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:0yyyyyy4322@192.168.4.32:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.4.40:5060;branch=z9hG4bK19A3144A

Remote-Party-ID: <sip:07492991578@192.168.4.40>;party=calling;screen=no;privacy=off

From: <sip:07492991578@192.168.4.40>;tag=22A6F1E4-2061

To: <sip:0yyyyyy4322@192.168.4.32>

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 71FFC8BC-A7EF11E5-B24CED9B-9CD509BC@192.168.4.40

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 1912428419-2817462757-2990992795-2631207356

User-Agent: Cisco-SIPGateway/IOS-15.5.1.T

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1450794655

Contact: <sip:07492991578@192.168.4.40:5060>

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 68

Session-Expires: 3600;refresher=uac

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 296

v=0

o=CiscoSystemsSIP-GW-UserAgent 6851 7202 IN IP4 192.168.4.40

s=SIP Call

c=IN IP4 192.168.4.40

t=0 0

m=audio 22492 RTP/AVP 8 100 101

c=IN IP4 192.168.4.40

a=rtpmap:8 PCMA/8000

a=rtpmap:100 X-NSE/8000

a=fmtp:100 192-194

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

4.- CUBE receives 100 Trying and 180 Ringing from CUCM

016936: //12498/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.4.40:5060;branch=z9hG4bK19A3144A

From: <sip:07492991578@192.168.4.40>;tag=22A6F1E4-2061

To: <sip:0yyyyyy4322@192.168.4.32>

Date: Tue, 22 Dec 2015 14:26:20 GMT

Call-ID: 71FFC8BC-A7EF11E5-B24CED9B-9CD509BC@192.168.4.40

CSeq: 101 INVITE

Allow-Events: presence

Content-Length: 0

016937: //12498/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 192.168.4.40:5060;branch=z9hG4bK19A3144A

From: <sip:07492991578@192.168.4.40>;tag=22A6F1E4-2061

To: <sip:0yyyyyy4322@192.168.4.32>;tag=3056396~5b01f916-ff84-482b-b2b5-cacb0ac4ceff-29806313

Date: Tue, 22 Dec 2015 14:26:20 GMT

Call-ID: 71FFC8BC-A7EF11E5-B24CED9B-9CD509BC@192.168.4.40

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

P-Asserted-Identity: "IT" <sip:20010@192.168.4.32>

Remote-Party-ID: "IT" <sip:20010@192.168.4.32>;party=called;screen=yes;privacy=off

Contact: <sip:0yyyyyy4322@192.168.4.32:5060>

Content-Length: 0

5.- CUBE sends 180 Ringing to ITSP

016943: //12497/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 88.x.x.9:5060;branch=z9hG4bK85ba699fee73d1559b04acfea3aa828a

From: <sip:07492991578@88.x.x..9>;tag=dztfn5od

To: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>;tag=22A6F248-1B4A

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

CSeq: 1 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: "IT" <sip:20010@192.168.4.40>;party=called;screen=yes;privacy=off

Contact: <sip:0yyyyyy4322@192.168.4.40:5060>

Server: Cisco-SIPGateway/IOS-15.5.1.T

Content-Length: 0

6.- CUCM sends CUBE 200 OK

017055: //12498/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.4.40:5060;branch=z9hG4bK19A3144A

From: <sip:07492991578@192.168.4.40>;tag=22A6F1E4-2061

To: <sip:0yyyyyy4322@192.168.4.32>;tag=3056396~5b01f916-ff84-482b-b2b5-cacb0ac4ceff-29806313

Date: Tue, 22 Dec 2015 14:26:20 GMT

Call-ID: 71FFC8BC-A7EF11E5-B24CED9B-9CD509BC@192.168.4.40

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence, kpml

Supported: replaces

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 3600;refresher=uac

Require: timer

P-Asserted-Identity: "Paul Kelly" <sip:20010@192.168.4.32>

Remote-Party-ID: "Paul Kelly" <sip:20010@192.168.4.32>;party=called;screen=yes;privacy=off

Contact: <sip:0yyyyyy4322@192.168.4.32:5060>

Content-Type: application/sdp

Content-Length: 211

v=0

o=CiscoSystemsCCM-SIP 3056396 1 IN IP4 192.168.4.32

s=SIP Call

c=IN IP4 10.1.1.1

t=0 0

m=audio 22494 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

7.- CUBE replies to CUCM with an ACK

017077: //12498/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:0yyyyyy4322@192.168.4.32:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.4.40:5060;branch=z9hG4bK19A4655

From: <sip:07492991578@192.168.4.40>;tag=22A6F1E4-2061

To: <sip:0yyyyyy4322@192.168.4.32>;tag=3056396~5b01f916-ff84-482b-b2b5-cacb0ac4ceff-29806313

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 71FFC8BC-A7EF11E5-B24CED9B-9CD509BC@192.168.4.40

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0

8.- CUBE sends 200 OK to ITSP

017114: //12497/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 88.x.x.9:5060;branch=z9hG4bK85ba699fee73d1559b04acfea3aa828a

From: <sip:07492991578@88.x.x.9>;tag=dztfn5od

To: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>;tag=22A6F248-1B4A

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

CSeq: 1 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: "Paul Kelly" <sip:20010@192.168.4.40>;party=called;screen=yes;privacy=off

Contact: <sip:0yyyyyy4322@192.168.4.40:5060>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-15.5.1.T

Session-Expires: 3600;refresher=uac

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 247

v=0

o=CiscoSystemsSIP-GW-UserAgent 5216 2338 IN IP4 192.168.4.40

s=SIP Call

c=IN IP4 192.168.4.40

t=0 0

m=audio 22490 RTP/AVP 8 101

c=IN IP4 192.168.4.40

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

9.- CUBE resends 200 OK to ITSP because CUBE is expecting to receive an ACK message from ITSP (CUBE resends the 200 OK for 7 times)

017116: //12497/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 88.x.x.9:5060;branch=z9hG4bK85ba699fee73d1559b04acfea3aa828a

From: <sip:07492991578@88.x.x.9>;tag=dztfn5od

To: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>;tag=22A6F248-1B4A

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

CSeq: 1 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: "Paul K" <sip:20010@192.168.4.40>;party=called;screen=yes;privacy=off

Contact: <sip:0yyyyyy4322@192.168.4.40:5060>

Supported: replaces

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-15.5.1.T

Session-Expires: 3600;refresher=uac

Require: timer

Supported: timer

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 247

v=0

o=CiscoSystemsSIP-GW-UserAgent 5216 2338 IN IP4 192.168.4.40

s=SIP Call

c=IN IP4 192.168.4.40

t=0 0

m=audio 22490 RTP/AVP 8 101

c=IN IP4 192.168.4.40

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

10.- As CUBE does not receive the ACK after 7 attempts to send the 200 OK, CUBE ends the call

017241: //12497/71FD5783B246/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:07492991578@88.x.x.9:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.4.40:5060;branch=z9hG4bK19A51CC4

From: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>;tag=22A6F248-1B4A

To: <sip:07492991578@88.x.x.9>;tag=dztfn5od

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

User-Agent: Cisco-SIPGateway/IOS-15.5.1.T

Max-Forwards: 70

Timestamp: 1450794683

CSeq: 101 BYE

Reason: Q.850;cause=86

P-RTP-Stat: PS=970,OS=155200,PR=0,OR=0,PL=0,JI=0,LA=0,DU=19

Content-Length: 0

Graham Old · ‎01-02-2016

I would be looking at the setup for the Sonicwall Firewall. It looks like it may not be handling the SIP protocol correctly.

In your first INVITE from the ITSP you have this

INVITE sip:0yyyyyy4322@195.x.x.1;user=phone SIP/2.0

I would have expected the Sonicwall to have converted the 195.x.x.1 IP address to the CUBE on 192.168.4.40

When you send the ACK to the ITSP you are defining the IP audio address as
c=IN IP4 192.168.4.40

You need the Sonicwall to convert that to the 195.x.x.1 address, If its failing to convert the INVITE its probably not converting the Audio IP address on the output.

Can you do a wireshark between the Sonicwall and the PSTN and check the Sonicwall is converting the IP addresses correctly

Graham

Rodrigo Marchina Soares · ‎01-02-2016

We are doing NAT from 192.168.4.40 to 195.x.x.1 (Public IP Address).

We can ping from 192.168.4.40 to 88.x.x.9.

The NAT is done after the Sonic Wall, in the ISP router.

I will return on 5th january at the customer and I will collect wireshark files.

Graham Old · ‎01-05-2016

You can't do a simple NAT to convert the IP address on SIP. You must have a SIP helper process that converts the IP address in the SIP protocol as well.

Why do you need to do NAT. Can you not assign the 195.x.x.1 address to the second NIC on the CUBE and make it do all the work. That is what CUBE's are for. To be the border element, to convert IP address and to provide security.

You need to setup a few extra things for security. I would suggest an access list on the second NIC to limit the IP address to Gamma's two IP address and the UDP port numbers. You should also make the IP routing to Gamma's IP address pretty tight.

I would suggest a few other things if you are able to connect the CUBE direct.

Graham

kelvin.blair · ‎01-15-2016

Rodrigo,

I'm not sure if you were able to resolve your problem, however I figured I would give you my two cents. Graham has pretty much giving you some good suggestions.. I had a similar issue with Sonicwall, but mine was more of an issue with Expressway behind a Sonicwall. The jabber clients had one-way audio. I must have changed every possible SIP ALG setting in the sonic wall to correct my issue with NAT. I was unable to find the right combination to make it successfully work. Note, I was able to get this same setup to work fine behind an ASA without issue. However, again "SIP INSPECTION" had to be turned on with the ASA for it to work.

Now considering my issue was with Expressway, i was able to convince the customer to move the Expressway-E outside of the Sonicwall. This ultimately solved my problem for this particular customer.

The suggestion that Graham has mentioned with using a second interface and directly attaching the CUBE is a solution that we know will work without issue. Just be sure to enable/configure the IOS firewall rules on the cube as well as lock it down to avoid any SIP Toll-Fraud attempts.

thanks,

Ayodeji Okanlawon · ‎01-02-2016

The reason why you are not getting ACK back from ITSP is that ACK is sent to the host filed in the contact header.

The address in the contact header here looks like its not reachable from your ITSP as it is a private address. Please correct this and your issue should be resolved

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 88.x.x.9:5060;branch=z9hG4bK85ba699fee73d1559b04acfea3aa828a

From: <sip:07492991578@88.x.x.9>;tag=dztfn5od

To: <sip:0yyyyyy4322@88.x.x.9:5060;user=phone>;tag=22A6F248-1B4A

Date: Tue, 22 Dec 2015 14:30:55 GMT

Call-ID: 383666-3659783180-846070@MSX76.gammatelecom.com

CSeq: 1 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: "Paul K" <sip:20010@192.168.4.40>;party=called;screen=yes;privacy=off

Contact: <sip:0yyyyyy4322@192.168.4.40:5060>

Please rate all useful posts

Rodrigo Marchina Soares · ‎01-02-2016

We are doing NAT from 192.168.4.40 to 195.x.x.1 (Public IP Address).

We can ping from 192.168.4.40 to 88.x.x.9.

Ayodeji Okanlawon · ‎01-03-2016

Your Nat isn't working correctly. The 200 OK contains the private ip add in the contact header. This is one of the issues with Nat. You need a device that can do SIP ALG.

As long as your contact header contains the private ip, your ITSP can't send ACK to the 200 OK

Please rate all useful posts

Rodrigo Marchina Soares · ‎01-03-2016

I understood what you mean.

The NAT is translating the ip header but not the SIP header.

I will check that on Tuesday.

Rodrigo Marchina Soares · ‎01-03-2016

Hi Ayodeji,

I will try to modify the SIP header with the configuration below on Tuesday. What do you think?

=====

voice class sip-profiles 10

request INVITE sip-header From modify "<sip:(.*)@195.x.x.1>” "<sip:\1@192.168.4.40>”

request ACK sip-header From modify "<sip:(.*)@195.x.x.1>” "<sip:\1@192.168.4.40>”

dial-peer voice 31 voip => (incoming SIP Calls)

voice-class sip profiles 10

=====

voice class sip-profiles 20

request INVITE sip-header From modify "<sip:(.*)@192.168.4.40>” "<sip:\1@195.x.x.1>”

request ACK sip-header From modify "<sip:(.*)@192.168.4.40>” "<sip:\1@195.x.x.1>”

dial-peer 32/33 voip => (outgoing SIP calls)

voice-class sip profiles 20

======

Rodrigo Marchina Soares · ‎01-05-2016

I haven't solved the problem yet.

Any idea to do the SIP ALG?

The ITSP is not sending the ACK to the 200 OK and it is not sending media from (88.x.x.10) to CUBE.

Only the CUBE is sending media to 88.x.x.10, that is the reason that only me can hear the customer.

mohmedsaber199020 · ‎02-16-2022

i have an issue like this and i'm waiting the advice too

https://community.cisco.com/t5/ip-telephony-and-phones/cube-issue-with-the-itsp-public-to-private-ip/m-p/4553419#M402211