SIP 100 Trying response code is part of the 1XX SIP Response Codes and one of the most commonly used SIP response codes in the SIP stack.
SIP works on a request-response model and 1xx SIP response codes are there to provide information on the status of network-related processes, SIP 100 Trying is one of them.
- 1 1xx SIP Response Codes in brief
- 2 SIP 100 TRYING
- 3 SIP 100 Trying Response Code Use Case Scenarios
Build pro IOS configs. FAST.
1xx SIP Response Codes in brief
1xx are informational or provisional messages. These messages let the caller know that its request is being handled by the User Agent Server (UAS).
1xx SIP Response code also referred to as SIP 100 messages are informational or provisional messages that inform callers that their request is being handled by the User Agent Server (UAS).
The diagram below illustrates a UAS and UAC process.
UAS and UAC
A SIP endpoint behaves both as a client and a server. When it sends a request, it’s a client. When it receives a request and sends a response, it behaves as a server.
Common 1xx SIP Response Codes
- 100 Trying
- 180 Ringing
- 181 Call is Being Forwarded
- 182 Queued
- 183 Session Progress
- 199 Early Dialog Terminated
Important notes on 1xx SIP Response Codes
- 100 SIP Response Codes are informational in nature and are also known as provisional responses.
- They may contain a message body with the exception of “100 Trying”.
- A UAS doesn’t always send a provisional response. It usually sends it if it knows it has enough time to process the request.
- The first informational response received by the UAC confirms that the INVITE it had sent, has been received by UAS. This mechanism is helpful in controlling the retransmission of INVITE messages in the network.
- VERY important point is that among the SIP messages, 1xx are the only ones that do NOT require an ACK.
SIP 100 TRYING
SIP 100 Trying is the most common 100 SIP response code.
It is an informational message that indicates your request is being processed and soon you can expect another SIP response from the other side.
100 Trying Basic SIP Call Flow – Step 1
In the figure above, SIP phone 2002 is registered with CUCM A and 1001 is registered with CUCM B. There is a SIP trunk between these 2 CUCM servers.
- Phone 2002 sends an INVITE to CUCM A asking for 1001.
- CUCM A responds with a 100 Trying.
- CUCM A sends the INVITE to next hop CUCM B.
When CUCM A responds with a 100 Trying, it is telling the caller phone 2002 that your request is being processed. It starts looking for the called party information in its database. Hence, for the time being, it sends a “provisional”100 Trying.
As you must be aware, CUCM is a call processing agent, hence it maintains a database of route patterns and directory numbers. It starts searching for the dialed pattern and its associated trunk/gateway through a process known as Digit Analysis (DA).
Upon identifying the routable pattern, it sends an INVITE to the next hop which is CUCM B in this particular case.
100 Trying Basic SIP Call Flow – Step 2
As you can see above, the next hop is CUCM B connected over the SIP trunk.
An INVITE is sent to this hop.
- CUCM B sends a 100 Trying to CUCM A and sends an INVITE to SIP phone 1001.
- 1001 informs CUCM B its’ ringing. This is conveyed in 180 Ringing.
- CUCM B sends180 Ringing to CUCM A which passes it on to the caller, who then hears a ring back tone.
- Phone 1001 picks up the call and sends a 200 OK to its CUCM B.
- CUCM B sends 200 OK to CUCM A >> 2002.
- This is acknowledged (ACK) by 2002 >> CUCM A and a two-way media/ communication are established between 2002 and 1001.
SIP 100 Trying Response Code Use Case Scenarios
The following scenarios will illustrate how SIP 100 Trying response code occur and acted upon by UC engineers.
100 SIP Response Codes Scenario# 1
Let’s go through another basic call flow to understand how SIP messages work.
Basic Call Flow Diagram Explained
- User A calls User B. User A’s PBX sends a setup message to the GW.
- GW understands this non-SIP message and creates a new SIP invite for the far end User B.
- User B SIP Phone sends a provisional 100 Trying to the GW.
- GW does not forward 100 trying to PBX but it creates an equivalent Call Proceeding message and sends over.
- User B sends another informational/provisional SIP message (180 Ringing) to GW which in turn sends “alerting” to the PBX.
- Now, User B picks up the call which generates a 200 OK. GW sends this confirmation to PBX as “Connect”. Since this is a final response, it is acknowledged with an ACK (message#10).
- Here the signaling is complete and RTP is established between User A and B.
- User B hangs up which generates a BYE message. The GW sends an equivalent “Disconnect” message towards the PBX. PBX sends a Release message to GW.
- GW sends a 200OK, thus confirming the termination of the session. It also sends a release complete to PBX.
100 SIP Response Codes Scenario# 2
After the initial response is received, and the CUCM sends an INVITE and receives a SIP 100 Trying. But, nothing happens.
How long will CUCM wait for another message?
Will it kill/expire the INVITE? Will it re-transmit the INVITE?
The answer lies in the explanation of SIP 100 Trying that we had discussed earlier. This provisional message indicates that a request has been received by the next-hop server and some action is being taken.
Therefore the response like any other provisional responses will STOP the re-transmission of an INVITE and CUCM then kicks in the SIP Expires timer.
100 SIP Response Codes Scenario# 3
Multiple 100 Trying messages from CUCM causing issues with call processing.
In CUCM logs, we see that CUCM is sending SIP 100 Trying repeatedly whenever we make calls to some OFF NET numbers.
WHY would CUCM send SIP 100 Trying for an outbound call?
One of the reasons could be a routing loop. CUCM matches a route pattern which is configured to reach a PBX/PSTN which in turn sends the call back into the CUCM system.
As a result, CUCM tries to find DN for inbound call and sends 100 Trying.
Thereafter, it searches for the route pattern instead and sends the call out (OFF NET), creating a loop in the process. This could be a result of poor dial plan design or a silly mistake of assigning correct partitions and Calling Search Spaces (CSS).
100 SIP Response Codes Scenario# 4
This may be an extension of scenario#3 elaborating another significant reason for routing a loop. Within CUCM, the Call Forward Unregistered (CFUR) functionality can also cause routing loops if a phone is unregistered.
The first call to the phone would cause the system to send a CFUR call to the phone’s DID through the PSTN. The resulting incoming PSTN call would then trigger another CFUR call attempt to reach the same phone’s DN, triggering yet another CFUR call from the central PSTN gateway through the PSTN. This cycle could repeat itself until the system’s resources are exhausted.
Configure the service parameter “MaximumForwardUnRegisteredHopsToDn”.
This sets a control mechanism on the maximum number of CFUR calls that are allowed for a DN at the same time.
Finally check your firewall configuration to see if the SIP messages are originating but not getting delivered to the destination.
100 SIP Response Codes Scenario# 5
A CUBE sends a 100 Trying towards CUCM but it never receives any messages back from CUCM. If there is a firewall in between and you see in CUCM logs that CUCM is responding, then of course something is blocking them and firewall is surely a good place to start with.
What happens when no response is received against a request you make or should you proceed to retry it again or just leave?
Of course, the request must be retried, but how will this be achieved?
Well, this is a function of SIP message timers.
The UA retries or re-transmits the message.
100 SIP Response Codes Scenario# 6
A SIP INVITE is re-tried if no response is received after a short while.
The Timers configuration is as per the IOS/Software running in CUBE/SBC or Message Timers; if it’s Cisco Unified Communications Manager (CUCM). Among the many benefits of timers, is their capability of improving the interoperability and performance of devices and network environments.
In CUCM, SIP timers are defined under Service Parameters.
Go to CUCM Admin > System > Service Parameters > Clusterwide Parameters (Device – SIP).
With respect to 100 Trying, CUCM’s configurable field is SIP Trying Timer.
This parameter will allow you to set maximum time that the CUCM will wait to receive a 100 response to an INVITE request.
There is a retry count timer also. This timer allows you to set the maximum number of times CUCM will re-send any SIP message. For example, Retry Count for SIP Rel1XX will specify the number of times that CUCM will re-send the reliable 1xx response message.
Build pro IOS configs. FAST.