SIP 404 Not Found response belongs to the 4xx SIP code group.
A group of SIP codes that indicate a request failure and constitutes a number of codes used by SIP for communicating errors and failures.
In this blog post we will explore the SIP 404 Not Found response code and touch the different available SIP Response Codes.
But, first what is SIP?
- 1 SIP Response Codes
- 2 404 NOT FOUND
- 3 SIP 404 Not Found use cases in Cisco Collaboration Architecture
- 4 Case Study – Validation of DN/Pattern/URI is configured on CUCM
- 5 Case Study – Inbound CSS on the SIP trunk does not have the desired route partition of the called party number.
- 6 Case Study – A common issue is when CUBE or SBC returns a 404 Not Found.
- 7 Case Study – CUCM may reject an inbound connection because of the large message size.
- 8 Conclusion
Build pro IOS configs. FAST.
Session Initiation Protocol or SIP is a peer-to-peer protocol (RFC3261) where ‘peers’ are the User Agents (UA). SIP can do the following:
- Create sessions, negotiate capabilities, modify and kill a ‘session’ between peers.
- Sessions include multimedia conferences, Internet telephony calls, video calls, multimedia distribution, notifications of events, and providing data on the state of endpoints.
- SIP devices can communicate:
- One to One (Unicast)
- One to Many (Multicast)
- Mesh of multiple unicast agents
- Or a combination of all as above
- UA can be a client or a server. A client makes a request while a server processes it and responds.
- A SIP endpoint can behave both as a client and a server.
SIP Response Codes
SIP communication is based on a Request-Response model or a client-server model. Here’s the thing: every request expects an answer.
For Example: If a request is accepted or successful, the response will be 200 OK, and if not, that could be termed as a re-direction, rejection, or just informational.
A SIP message is either a request from a client to a server or a response from a server to a client.
SIP has defined status codes for responses indicating the nature or class of the response:
- 1xx – Informational Responses
Example: 100 Trying or 180 Ringing
- 2xx – Success
Example: 200 OK or 202 Accepted
- 3xx – Redirection
Example: 302 Moved Temporarily
- 4xx – Request Failure
Example: 404 Not Found, 407 Proxy Authorization Required or 408 Request Timeout
- 5xx – Server Failure
Example: 503 Service Unavailable or 505 SIP Version Not Supported
- 6xx – Global Failure
Example: 603 Decline or 604 Does Not Exist Anywhere
All responses, except for 1xx responses, are considered final and are acknowledged with an ACK. Thus, if a 200 OK is sent by Phone A to Phone B, then Phone B must send an ACK for 200 OK.
Let’s now discuss in detail one of the most common SIP responses; 404 Not Found.
404 NOT FOUND
While browsing, have you ever received a “404 Not Found” response? That’s because the Web server has no knowledge of the requested page. Many SIP response codes were based on HTTP version 1.1.
SIP 404 Not Found is also a valid SIP “client error class” response in a request to an unknown user. However, SIP is not an extension of HTTP.
SIP 404 Not Found Error Response
- The server has information that the user does not exist at the domain specified in the Request-URI.
- Indicates the destination you are trying to reach is unreachable because the number is not allocated/defined.
- The requested user is not currently signed on with the user agent. See the snippet below:
SIP/2.0 404 the member requested is not available Via: SIP/2.0/UDP x.x.x.x:60000;branch=z9hG4bK1 From: Jazz Hope<sip:[email protected]>;tag=5 To: <sip:[email protected];user=ip>;tag=f6 Call-ID: [email protected] CSeq: 55 INVITE
SIP 404 Not Found use cases in Cisco Collaboration Architecture
Cisco products may respond with a SIP 404 Not Found in the following scenarios:
- Directory Number (DN) not defined in CUCM.
- Desired Route Pattern does not exist on CUCM.
- No SIP route pattern to route this number or DN.
- Directory URI not assigned.
Case Study – Validation of DN/Pattern/URI is configured on CUCM
The best place to validate whether your desired DN/Pattern/URI is configured on CUCM or not; is the Route plan Report.
Log in to CUCM Admin > Call Routing > Route Plan Report. Put your DN into the search box and hit Find. You should get a result as shown below.
Keeping the search empty will give a full list of patterns. If you are an excel guy, just download the report in CSV and open it with Microsoft Excel.
The default fine name is NumPlan.csv.
The Phone/Soft client you are trying to reach is not registered with the server. Go to CUCM Admin > Device > Phone > Search
Case Study – Inbound CSS on the SIP trunk does not have the desired route partition of the called party number.
A little bit about CSS. CSS is a collection of route partitions. DNS must belong to some partition (could be None as well). These partitions are searched to determine how to route calls to any number. CSS of the calling device must have the partition of the called number.
Check which CSS is set on your trunk.
Go to CUCM Admin > Device > Trunk >Look for your Trunk and open its trunk configuration page.
Under Inbound Calls section >you will find the Calling Search Space field. Ensure that this CSS has the desired partition.
CSS Is Configured but Call is Failing
We don’t have to dig into logs right now as CUCM offers a tool called “Dialed Number Analyzer” which will tell you if the desired destination is routable from the trunk or not.
Open CUCM Serviceability > Tools > Dialed Number Analyzer > Analysis > Trunks > Select the trunk from the list. Fill in the calling party and dialed digits info and hit “Do Analysis”
The result will be something like this. Expand All to see the complete route.
A DNA tool can also be used to check the call routing path for outbound GW/PSTN calls.
Case Study – A common issue is when CUBE or SBC returns a 404 Not Found.
If the configuration was done properly with dial-peers, the reason for the error could be that CUBE/SBC expects to see full calling party number but CUCM is sending only a 4 digit internal extension in the From field of the INVITE.
In such a scenario, it’s essential to check why CUCM is sending a 4 digit internal extension, instead of a full calling party number. One reason could be that on DN’s line config, we have External Phone Number Mask set to 4 digit ext.
Next place to watch out for is Route Pattern and the Route List. CUCM gives priority to RL-RG config > Route Pattern > Device Line page config when it comes to using external phone number mask. See below:
This is the order of precedence from least to max.DN’s line config.
Route Pattern = If “Use Calling Party’s External Phone Number Mask” checkbox is checked, then it will pick from the DN’s line config. Else, it will pick from Calling Party Transformation Mask.
RL detail config page = If “Use Calling Party’s External Phone Number Mask” set to Off, and Calling Party Transform Mask blank, nothing will go out. Set Calling Party Transform Maskto desired number or select “On”.
Path: Call Routing > Route Hunt/List > Route List > Route List Details > Select the RG > Route List Detail Configuration > Under Calling Party Transformations > Use Calling Party’s External Phone Number Mask
Case Study – CUCM may reject an inbound connection because of the large message size.
This cause may not be very common but can be caused by the service parameter “SIP Max Incoming Message Size” has been modified from the default size of 18000 (see snippet below).
Line 45535: 21620165.007 |11:46:14.820 |AppInfo |SIPTcp – Ignoring large message from xx.xx.xx.xx:. Only allow up to 5000 bytes. Resetting connection.
Check CUCM > System > Service Parameters > Active server >CallManger (Active) > Advanced > Under ” Clusterwide Parameters (Device – SIP)” > SIP Max IncomingMessage Size.
I have also seen database replication causing weird issues.
For example, if you find all the config in place i.e. DN is defined, CSS and partitions are fine, the device is registered, DA is fine, and your Route Plan report does not show overlapping patterns, etc but the internal calls are returning 404 Not Found, then you should check replication.
Check the utils dbreplicationruntimestate
Last but not least sometimes (rarely) a DN previously configured but later on deleted does not get cleared up in the IMDB DB of the CUCM. Restarting the CCM service may resolve this issue.
Build pro IOS configs. FAST.
I hope that in this blog, you were able to clearly understand SIP 404 Not Found response code and learn more about the different available SIP Response Codes.
As UC Engineers, it is important that we keep ourselves up to date and well educated on anything relative to our industry. You have an edge when you continue to hone your skills thru learning.
That’s why if you find this post helpful, please feel free to share to your peers. And if you have any questions, just drop them in the comment section and I will get back to you right away.