IMS

Retry

What happens when the other party is not responding ?

What is a DUT supposed to do when the other party is not responding to a certain SIP message it has sent ?

Theorectically you can think of a couple of cases as follows.

Case 1 : Waiting for the response forever and never retry

Case 2 : Retry (resend the message) forever until it gets the expected response

Case 3 : Retry several times and give up if it does not get the expected response.

Is there any specification on determining which case a DUT take ?

Now you would have a lot of questions boggling in your mind. Is there any specification on which case a DUT should take ? Would a DUT apply the same rule (case) to all SIP message or take different rules for different message ? If a DUT takes case 3, is there any specific numbers for retry that applies to every SIP message ? or they would retry depending on specific SIP messages ? If it decided to retry, what is the time interval between each retry ? Is the time interval constant for each retry ? or a certain back-off algorithm works ?

I haven't confirmed all of these details in specification (e.g, RFC, 3GPP, GSMA etc), but according to my experience 'there seems to be general guideline but the detailed behavior varies depending DUT implementation or the requirement from service provider. So I decided to describe the retry behavior based on some specific SIP messages and leave the details up to your own observation.

Retry Timer

Even though I don't see any hard and clear rules about retry and the intervals between the retry, there seems to be a broad guideline for retry and a couple of timers working in SIP stack as described in https://andrewjprokop.wordpress.com/2013/07/02/understanding-sip-timers-part-i/ . According to this blog, there are three major timers that can be summerized as follows.

Sound simple ?

Actually it is not simple as you might think because sometimes multiple Timers are working together and even within the timer expiration period DUT would apply a certain type of back-off algorithm. In addition, each service provider may put their own criteria for some specific SIP message.

So, if you check the retry timer from the log you captured, the behavior would appear to be pretty complicated.

Retry - REGISTER

This is an example case where CSCF does not respond to REGISTER message from a DUT. As you see, in this case UE retries 4 more times. If you closely look into the retry interval, you would notice it would go like 2,4,6,16 sec.

Then you may ask 'Is 4 times retry fixed for all DUT ?'.  Is Retry timer interval supposed to be always like this ?

More importantly, what is the DUT supposed to do after 4 times retry ? Give up forever ? or retry after a certain time period ?

This specific DUT that I used never retry after 4 times retry before I wait for over 90 min and give up, but I think I saw a certain requirement from a service provider saying that DUT shall retry after a certain period of registration failure.

Retry - INVITE

According to the definition of T1 timer mentioned above, it implies that DUT would retry INVITE if it does not get any response. But the DUT that I have used, it didn't retry at all.. it just waited for about 40 sec and popup call failure on DUT screen and retry IMS Registration. The behavior may be different if I use another device for other service provider. If I find another UE that perform retry, I will post the log here.

Retry - UPDATE

This is an example case where the other party does not respond to UPDATE message from a DUT. As you see, in this case UE retries 5 more times. If you closely look into the retry interval, you would notice it would go like 0.5,1,2,4 sec.

You see an example here in which a special back-off algorithm is applied. After basic T1 timer, the interval goes like 2^0, 2^1, 2^2