Re: Static SIP Service

Yort Mantup · ‎02-05-2019

Moving from a dynamic SIP solution to static SIP. I completed the setup and have the sip trunk registered and when making a call to the test number assigned to the SIP trunk, my phone rings but the call does not pick up and eventually goes busy. My first thought is it's a codec issue but I have not found where that is the case.

ITSP --> SIP --> CUBE --> SIP --> CUCM --> IP Phone

I attached the debug for the incoming call.

R0g22 · ‎02-05-2019

There is a timeout happening -

005208: Feb 5 2019 19:27:51.034 UTC: %VOICE_IEC-3-GW: SIP: Internal Error (ACK wait timeout): IEC=1.1.129.7.66.0 on callID 1180 GUID=EE74742F28B211E98551D21BBC9A1796
005209: Feb 5 2019 19:27:51.035 UTC: //1180/EE74742F8551/CCAPI/cc_api_call_disconnected:
Cause Value=102, Interface=0x7F63D8CBBEA8, Call Id=1180
005210: Feb 5 2019 19:27:51.035 UTC: //1180/EE74742F8551/CCAPI/cc_api_call_disconnected:

Add "debug ccsip message" to your existing debugs and make another test call.

Yort Mantup · ‎02-05-2019

Thank you for the response. Please see new debug file with debug ccsip message enabled.

Jay Schulze · ‎02-05-2019

Hello,

Looking at the debugs. One thing that is pretty clear. Your ITSP never acks the 200ok that is sent out for the outside leg.

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 209.142.200.14:5060;branch=z9hG4bKbt36sc300o083b2b3oc0.1
From: "Putnam Troy" <sip:6162831477@10.1.6.4>;tag=5151883
To: <sip:6162775094@10.1.6.47:5060>;tag=4760FAB-152C
Date: Tue, 05 Feb 2019 19:54:10 GMT
Call-ID: 1548058228-14266198@SFLDMIUP-C3SIPGW
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
P-Asserted-Identity: "Troy Putnam" <sip:7771350@192.77.235.171>
Contact: <sip:6162775094@192.77.235.171:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-16.6.4
Session-ID: 1920f7f300105000a00000cae54049f2;remote=fe8eed17b6005db896eddf7fcf175241
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 252

And even more strange they continue to send invites in for the call. yet the cseq is still 1.

nagaraj789 · ‎02-06-2019

Can you also attached running config?

Yort Mantup · ‎02-06-2019

See attached

PierMatteo · ‎02-06-2019

Hi,

in your answer to the provider you send the following contact header:

Contact: <sip:6162775094@192.77.235.171:5060>

That is an internal IP that a public provider can't answer upon. So you would need a firewall in front that rewrites that header. It also does not match your CUBE's IP. You could check with what IP you're registering your trunk (check the REGISTER method). It could be that the provider is not able to answer your requests.

Jay Schulze · ‎02-06-2019

Couldn't they just use a sip profile to modify the contact header?

PierMatteo · ‎02-07-2019

If they don't have a firewall in front they would need to, yes :-) And it would be easier too.

But I guess there should be a NAT in front which could take care of that.

What is the IP your CUBE registers with the provider?

Yort Mantup · ‎02-07-2019

Thanks for the responses. We are moving from a dynamic sip solution to a static so I have not defined a SIP profile (request REGISTER, INVITE, etc) thinking I did not need to. Maybe I do.

The 192.77.235.171 is as you stated, our public IP address or Source IP> The destination IP (SIP provider) is 209.142.200.14.

PierMatteo · ‎02-07-2019

Why is your *inbound provider dial-peer*

dial-peer voice 200 voip

shutdown?

BTW, are you able to do outbound calls? As the guys stated before, either your responses do not reach the provider, or the provider cannot contact you.

Yort Mantup · ‎02-07-2019

Sorry, I was troubleshooting prior and shut that dial-peer off. It was enabled during the captures I provided. I was just on the call with the carrier and I questioned this piece of the debug output below (specifically the part underlined and bolded. The 10.1.6.x is the carrier internal network. I should be sending the destination of 209.142.200.xxxx. From what I gather, I am retaining their internal IP's and not sending the 209.142.200.xxxx in the FROM and TO. I am unsure how to remedy that.

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 172.20.1.98:5060;branch=z9hG4bKD32204

From: "Putnam Troy" <sip:6162831477@209.142.200.14>;tag=DBD39BC-235F

To: <sip:6162775094@172.20.1.104>

Date: Thu, 07 Feb 2019 15:08:28 GMT

Call-ID: F3A2E8B-2A2111E9-AEAAD21B-BC9A1796@172.20.1.98

CSeq: 101 INVITE

Allow-Events: presence

Content-Length: 0

103409: Feb 7 2019 15:08:28.984 UTC: //11514/0F3832BDAEA4/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 172.20.1.98:5060;branch=z9hG4bKD32204

From: "Putnam Troy" <sip:6162831477@209.142.200.14>;tag=DBD39BC-235F

To: <sip:6162775094@172.20.1.104>;tag=32856804~9e135f52-c30b-4970-9ce6-aa055143ce9a-59865179

Date: Thu, 07 Feb 2019 15:08:28 GMT

Call-ID: F3A2E8B-2A2111E9-AEAAD21B-BC9A1796@172.20.1.98

CSeq: 101 INVITE

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

Allow-Events: presence

Server: Cisco-CUCM11.5

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-ID: 00002fed00105000a00080ce623bf878;remote=b6f9ac70b0d253ea9657216eb0d80351

P-Asserted-Identity: "Troy Putnam" <sip:7771350@172.20.1.104>

Remote-Party-ID: "Troy Putnam" <sip:7771350@172.20.1.104>;party=called;screen=yes;privacy=off

Contact: <sip:6162775094@172.20.1.104:5060>;+u.sip!devicename.ccm.cisco.com="CSFTPutnam";video;bfcp

Content-Length: 0

103410: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:

Calling Number=, Called Number=6162775094, Peer Info Type=DIALPEER_INFO_SPEECH

103411: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:

Match Rule=DP_MATCH_DEST; Called Number=6162775094

103412: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:

Result=Success(0) after DP_MATCH_DEST

103413: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0

103414: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:

Result=SUCCESS(0)

List of Matched Outgoing Dial-peer(s):

1: Dial-peer Tag=100

103415: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/SIP/Error/ccsip_reg_search_reg_number_table:

No entry found in reg Number Table for 6162831477

103416: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/SIP/Error/ccsip_reg_search_reg_number_table:

No entry found in reg Number Table for 6162775094

103417: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/SIP/Error/sipSPI_validate_own_ip_addr:

ReqLine IP addr does not match with host IP addr

103418: Feb 7 2019 15:08:28.985 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:

Calling Number=, Called Number=6162831477, Peer Info Type=DIALPEER_INFO_SPEECH

103419: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:

Match Rule=DP_MATCH_DEST; Called Number=6162831477

103420: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:

Result=Success(0) after DP_MATCH_DEST

103421: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=0

103422: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:

Result=SUCCESS(0)

List of Matched Outgoing Dial-peer(s):

1: Dial-peer Tag=100

103423: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

Calling Number=7771350, Called Number=, Voice-Interface=0x0,

Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,

Peer Info Type=DIALPEER_INFO_SPEECH

103424: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

Result=NO_MATCH(-1) After All Match Rules Attempt

103425: Feb 7 2019 15:08:28.986 UTC: //-1/xxxxxxxxxxxx/DPM/dpMatchSafModulePlugin:

dialstring=NULL, saf_enabled=0, saf_dndb_lookup=0, dp_result=-1

103426: Feb 7 2019 15:08:28.987 UTC: //11513/0F3832BDAEA4/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 209.142.200.14:5060;branch=z9hG4bKmtpboj20d82rk2hsej70.1

From: "Putnam Troy" <sip:6162831477@10.1.6.4>;tag=4192693

To: <sip:6162775094@10.1.6.47:5060>;tag=DBD39F7-EF6

Date: Thu, 07 Feb 2019 15:08:28 GMT

Call-ID: 1548058228-14743757@SFLDMIUP-C3SIPGW

CSeq: 1 INVITE

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

Allow-Events: telephone-event

P-Asserted-Identity: "Troy Putnam" <sip:7771350@192.77.235.171>

Contact: <sip:6162775094@192.77.235.171:5060>

Server: Cisco-SIPGateway/IOS-16.6.4

Session-ID: 00002fed00105000a00080ce623bf878

PierMatteo · ‎02-07-2019

Is the provider's IP always the .14 or can it vary?

You could give this a go...:

-> profile 200 should copy the IP from the provider into a variable and you can use it to modify

-> profile 201 sets the .14 as a fixed IP

... maybe I'm missing something but I guess it' worth a try.

voice class sip-profiles 201
 rule 10 request ANY sip-header To modify "sip:(.*)@.*>" "sip:\1@209.142.200.14:5060>"
 rule 11 request ANY sip-header From modify "sip:(.*)@.*>" "sip:\1@209.142.200.14:5060>"
 rule 20 response ANY sip-header To modify "sip:(.*)@.*>" "sip:\1@209.142.200.14:5060>"
 rule 21 response ANY sip-header From modify "sip:(.*)@.*>" "sip:\1@209.142.200.14:5060>"
!
voice class sip-copylist 200
 sip-header from
 sip-header to
!
voice class sip-profiles 200
 rule 10 request INVITE peer-header sip To copy "sip:.*@(.*)>" u01
 rule 11 request INVITE peer-header sip From copy "sip:.*@(.*)>" u02
 rule 20 response ANY sip-header To modify "sip:(.*)@.*>" "sip:\1@\u01>"
 rule 21 response ANY sip-header From modify "sip:(.*)@.*>" "sip:\1@\u02>"
!
dial-peer voice 200 voip
 description Incoming dial-peer
 voice-class sip profiles 200 inbound
 voice-class sip profiles 201
!
dial-peer voice 201 voip
 description Outgoing 11 digit dial-peer
 voice-class sip profiles 201
!
dial-peer voice 202 voip
 description Outgoing 911 dial-peer
 voice-class sip profiles 201
!

Yort Mantup · ‎02-07-2019

Thanks! I was just looking at a similar solution reading thru some documentation. I followed your steps but no change. After testing I show it exclusively uses dial-peer 100 only. No reference to dial-peer 200. I also noticed that invite includes the 10.1.6.xx ip address.

Yes - it is always the .14 ip.

Was I supposed to include something further here after the from and to?

voice class sip-copylist 200
 sip-header from
 sip-header to

PierMatteo · ‎02-07-2019

I'm wondering why would match only dial-peer 100, as it is your CUCM dial-peer. I was expecting that an Inbound call coming from the provider would match one of the 20x dial-peers. Can you check (debug voip ccapi inout) what's your inbound DP when calling Inbound? No nothing to add to the copy list..but we're also not applying it at the moment.