Is the ITSP sending a username not a called number? Here's a Potential Fix!

The Issue

After setting up a new registering type SIP Trunk with a new Internet Telephony Service Provider, we were having 404 not found issues on inbound calls.  It turns out that our registration username credentials were being included in the Invite on inbound calls.  This is not actually a valid number, which causes issues with CUBE and CUCM (as they look at the number in the Invite field to match the desired number of where to ultimately route the call).

Relevant Starting SIP Configuration

We are using a Voice Class Tenant setup for SIP Server Registration.  Note our credentials username below as it will become important.

voice class tenant 900

registrar dns:sbc.mysiplogin.net expires 240

credentials username 0504222412 password 7 141105452451D3D realm simplelogin.net

authentication username 0504222412 password 7 130301B23434F333C realm sip.mysipresource.com

sip-server dns:sbc.mysiplogin.net

no connection-reuse

session transport udp

no session refresh

url sip

error-passthru

rel1xx disable

asserted-id pai

bind control source-interface GigabitEthernet0/0/1

bind media source-interface GigabitEthernet0/0/1

no pass-thru content custom-sdp

outbound-proxy dns:sbc.mysiplogin.net

privacy-policy passthru

!

Example Inbound Call Failure

After attempting to place inbound test calls, we were getting a dreaded telco message “Your number cannot be completed as dialed”.  Pretty quickly after running debug ccsip messages, the number in the Invite stood out as odd as it obviously isn't a phone number.  One thing you may note, is that we do see the expected called phone number in the To: field below. 

Let’s not jump to any conclusions just yet…

Received:

INVITE sip:0504222412@192.168.100.10:5060 SIP/2.0

Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK-524287-1-ZWZiZTkxMmUwNGZkNTZjNzkxN2FmNDk0ZmFhZThkYWI.--f6f06ee6c381498f6bf81b46ed2a4d69;rport

Via: SIP/2.0/UDP 60.60.60.60:5060;branch=z9hG4bK-524287-1-ZmE5NjU2NTM0MjE5YjcxMDkzZTZkMWE0NWFjYTE2YTE.--6e82d96f44524787d61d5e6ba4c42cec;rport=5060

Via: SIP/2.0/UDP 64.52.82.32:5070;rport=5070;branch=z9hG4bK-u6ifca6jjm5xntdd

Max-Forwards: 68

Record-Route: <sip:10.10.10.10;lr;ep;pinhole=UDP:38.46.50.140:52945>

Record-Route: <sip:60.60.60.60;lr;ep>

Contact: sip:64.52.82.32:5070

To: <sip:15554443333@sbc.mysiplogin.net>

From: <sip:15556667777@sbc.mysiplogin.net>;tag=oqgfu6sw4qnyht7l.o

Call-ID: 440927575_99470098@67.231.9.166

CSeq: 156 INVITE

Expires: 300

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

Content-Disposition: session

Content-Type: application/sdp

User-Agent: PortaSIP

P-Asserted-Identity: <sip:15556667777@sbc.mysiplogin.net>

Remote-Party-ID: <sip:15556667777@sbc.mysiplogin.net>;party=calling

h323-conf-id: 1530637927-1272907761-3904560815-2771800291

cisco-GUID: 1530637927-1272907761-3904560815-2771800291

Content-Length: 240

v=0

o=PortaSIP 3325523434792329328 1 IN IP4 64.52.82.32

s=SIP Media Capabilities

t=0 0

m=audio 60146 RTP/AVP 0 101

c=IN IP4 64.52.82.32

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=ptime:20

Here, we see CUBE sending an invite for the call to CUCM as we would hope for the next step.  But now the To: field here looks quite suspicious as it now has our credentials username instead of the called phone number…

Invite Sent to CUCM

Sent:

INVITE sip:0504222412@192.168.200.10:5060 SIP/2.0

Via: SIP/2.0/TCP 192.168.1.1:5060;branch=z9hG4bKA332114

From: <sip:15556667777@sbc.mysiplogin.net>;tag=3F226A2-3B6

To: <sip:0504222412@192.168.200.10>

Date: Fri, 05 Sep 2025 00:07:50 GMT

Call-ID: 31F2286F-892311F0-A26B8DA6-A0ED073D@192.168.1.1

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

Min-SE:  1800

Cisco-Guid: 1530637927-1272907761-3904560815-2771800291

User-Agent: Cisco-SIPGateway/IOS-16.6.8

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

CSeq: 101 INVITE

Timestamp: 1757030870

Contact: <sip:15556667777@192.168.1.1:5060;transport=tcp>

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 67

P-Asserted-Identity: <sip:15556667777@192.168.1.1>

Session-ID: 60f190f13f3a51128a8b62a651972cd2;remote=00000000000000000000000000000000

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 249

v=0

o=CiscoSystemsSIP-GW-UserAgent 4411 354 IN IP4 192.168.1.1

s=SIP Call

c=IN IP4 192.168.1.1

t=0 0

m=audio 13870 RTP/AVP 0 101

c=IN IP4 192.168.1.1

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

Finally, below you can see that CUCM is responding back with a 404 Not Found.  This isn’t really too surprising, given that we don’t have any phone numbers in CUCM that match the credential username for our ITSP SIP Trunk…

Received from CUCM

Received:

SIP/2.0 404 Not Found

Via: SIP/2.0/TCP 192.168.1.1:5060;branch=z9hG4bKA3A5FD

From: <sip:15556667777@sbc.mysiplogin.net>;tag=3F22BC6-2226

To: <sip:0504222412@192.168.20.11>;tag=69428025~e8515f59-57fd-4061-a503-0ce0bdbb44f0-42533055

Date: Thu, 04 Sep 2025 22:04:03 GMT

Call-ID: 32BB1D28-892311F0-A2858DA6-A0ED073D@192.168.1.1

CSeq: 101 INVITE

Allow-Events: presence

Reason: Q.850;cause=1

Server: Cisco-CUCM12.5

Session-ID: 00000000000000000000000000000000;remote=ec1f107138245f4886c9303aeabcf30b

Content-Length: 0

SIP Header Configuration Adjustment Time To The Rescue!

Step 1

After some research, we decided we need to modify the SIP Invite header and ensure that the To: field will contain the called phone number so that things flow normally.  In our case, in order to modify inbound calls with a sip server tenant setup, this requires creating a voice class sip-profiles and applying those to our sip-server tenant.

voice class sip-profiles 900

 request INVITE sip-header To copy "sip:(.*)@" u01

 request INVITE sip-header SIP-Req-URI modify ".*@(.*)" "INVITE sip:\u01@\1"

Step 2

Now the first step to applying this sip-profiles on inbound calls is to add sip-profiles inbound under voice service voip - sip.  This will enable the sip-profiles inbound globally, but does not map our specific sip profile.

voice service voip

sip

  sip-profiles inbound

Step 3

Next, we need to apply the sip-profiles to our specific sip-server tenant. 

voice class tenant 900

  registrar dns:sbc.mysiplogin.net expires 240

  credentials username 0504222412 password 7 141105452451D3D realm simplelogin.net

  authentication username 0504222412 password 7 130301B23434F333C realm sip.mysipresource.com

  sip-server dns:sbc.mysiplogin.net

  no connection-reuse

  session transport udp

  no session refresh

  url sip

  error-passthru

  rel1xx disable

  asserted-id pai

  bind control source-interface GigabitEthernet0/0/1

  bind media source-interface GigabitEthernet0/0/1

  no pass-thru content custom-sdp

  sip-profiles 900 inbound

  outbound-proxy dns:sbc.mysiplogin.net

  privacy-policy passthru

NOTE:   If you just have a global sip-server setup, you can likely apply the sip-profiles to the applicable dial-peers or even globally under voice service voip.

The Moment of Truth: YES!

After placing a test call, we finally hear ringing and success!  See the ccsip messages debug below showing that we are now modifying the number in the SIP invite header to contain that of the actual called number.  Also, the To: field also contains the called number as well on messages sent to CUCM.

Received from SIP ITSP

Received:

INVITE sip:0504222412@192.168.100.10:5060 SIP/2.0

Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK-524287-1-NDkwZmZlMWI3ZTllZmM5YzM2MjZmZjZkYTVlMGE1M2U.--7f91de8ff9c9baa96e971586015c97d4;rport

Via: SIP/2.0/UDP 60.60.60.60:5060;branch=z9hG4bK-524287-1-MDNlODI0MzY2N2YyMTYwMWZmNjNjNzQ2OGFkM2JjYmY.--2ec878b5a95af596e013500701628e6a;rport=5060

Via: SIP/2.0/UDP 64.52.82.32:5073;rport=5073;branch=z9hG4bK-wflv2gjoo3rmg5h5

Max-Forwards: 68

Record-Route: <sip:10.10.10.10;lr;ep;pinhole=UDP:38.46.50.140:52945>

Record-Route: <sip:60.60.60.60;lr;ep>

Contact: sip:64.52.82.32:5073

To: <sip:15554443333@sbc.mysiplogin.net>

From: <sip:15556667777@sbc.mysiplogin.net>;tag=gb5k3nu3oak5tetl.o

Call-ID: 438346894_123690835@67.231.9.166

CSeq: 174 INVITE

Expires: 300

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

Content-Disposition: session

Content-Type: application/sdp

User-Agent: PortaSIP

P-Asserted-Identity: <sip:15556667777@sbc.mysiplogin.net>

Remote-Party-ID: <sip:15556667777@sbc.mysiplogin.net>;party=calling

h323-conf-id: 2746835760-2944354148-309272091-3070675725

cisco-GUID: 2746835760-2944354148-309272091-3070675725

Content-Length: 240

v=0

o=PortaSIP 2744963517100136020 1 IN IP4 64.52.82.32

s=SIP Media Capabilities

t=0 0

m=audio 46948 RTP/AVP 0 101

c=IN IP4 64.52.82.32

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=ptime:20

Invite Sent to CUCM

Sent:

INVITE sip:15554443333@192.168.200.10:5060 SIP/2.0

Via: SIP/2.0/TCP 192.168.1.1:5060;branch=z9hG4bKA42158A

From: <sip:15556667777@sbc.mysiplogin.net>;tag=3F5ACC3-26E3

To: <sip:15554443333@192.168.200.10>

Date: Fri, 05 Sep 2025 00:11:41 GMT

Call-ID: BB996A8E-892311F0-A2978DA6-A0ED073D@192.168.1.1

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

Min-SE:  1800

Cisco-Guid: 2746835760-2944354148-0309272091-3070675725

User-Agent: Cisco-SIPGateway/IOS-16.6.8

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

CSeq: 101 INVITE

Timestamp: 1757031101

Contact: <sip:15556667777@192.168.1.1:5060;transport=tcp>

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 67

P-Asserted-Identity: <sip:15556667777@192.168.1.1>

Session-ID: f368e0a573525b1ba5b9177b53aafc90;remote=00000000000000000000000000000000

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 249

v=0

o=CiscoSystemsSIP-GW-UserAgent 1829 949 IN IP4 192.168.1.1

s=SIP Call

c=IN IP4 192.168.1.1

t=0 0

m=audio 13902 RTP/AVP 0 101

c=IN IP4 192.168.1.1

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

Received from CUCM

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/TCP 192.168.1.1:5060;branch=z9hG4bKA42158A

From: <sip:15556667777@sbc.mysiplogin.net>;tag=3F5ACC3-26E3

To: <sip:15554443333@192.168.200.10>;tag=9269244~e8515f59-57fd-4061-a503-0ce0bdbb44f0-23298623

Date: Thu, 04 Sep 2025 22:07:53 GMT

Call-ID: BB996A8E-892311F0-A2978DA6-A0ED073D@192.168.1.1

CSeq: 101 INVITE

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

Allow-Events: presence

Server: Cisco-CUCM12.5

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

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-ID: 4b4a081a00105000a0006026aaa6a3ae;remote=f368e0a573525b1ba5b9177b53aafc90

P-Asserted-Identity: "A User" <sip:3333@192.168.200.10>

Remote-Party-ID: "A User" <sip:3333@192.168.200.10>;party=called;screen=yes;privacy=off

Contact: <sip:15554443333@192.168.200.10:5060;transport=tcp>;+u.sip!devicename.ccm.cisco.com="SEP6026AAA6A3AE"

Content-Length: 0

Wrapping Things Up

In conclusion, it's clear that the wrong number in the SIP Invite header was the culprit behind our 404 Not Found debacle. A quick-witted adjustment to the CUBE's SIP profiles was all it took to get things back on track. Now, incoming calls are happily ringing away, proving that sometimes, even in the world of VOIP, it's not you; it's the invite header that's the problem.