In Understanding SIP Timers Part I, I explained the basics of T1, Timer B, and Timer F. Today I want to climb up the protocol stack a bit and write about timing from a services point of view. Timers B and F function close to the network layer and are responsible for making sure that messages are received by the next hop. They aren’t particularly interested in what those messages are attempting to do. This next level of timing is context aware and message type is of great importance.
I’ll begin with a brief description of the four parts of a SIP message. First, there is the Request Line. This is a single line of text that contains the SIP request or response type, the SIP URI of the destination, and the protocol version. Examples include:
INVITE sip:aprokop@sipguy.com SIP/2.0
and
SIP/2.0 200 OK
Following the Request Line is a series of headers. These headers describe who the request or response is coming from, the call ID, the IP addresses of the SIP elements that the packet traversed, and many more things about the message. Example headers include:
Content-Type: application/sdp
Content-Length: 115
User-Agent: AVAYA-SM-6.1.1.0.611023
Event: Message-Summary
After the headers section is a blank line. This blank line is used to separate the SIP protocol components from the message body. For example, a blank line would come between the last header in a SIP Invite request and the SDP (Session Description Protocol) message body. All SIP messages have the blank line, but the message body is optional.
Service level timing occurs in the header section. Specifically, it uses the Expires header. The Expires header indicates the lifespan of a particular operation. If contained within an Invite message, the Expires header specifies the amount of seconds the Invite will exist without being answered. In other words, if the Expires contained a value of 60, the Invite would timeout and be canceled in one minute if a “200 OK” was not received by the sender.
Expires: 3600
Expires headers are used by other SIP messages. Inside a Register request, an Expires header designates the lifespan of the registration. If it contains 3600, the registration will timeout in one hour and at that point become invalid. You cannot call someone with an expired registration. The SIP proxy will not forward on your Invite.
Expires headers are used in Subscribe messages and the same timeout policies apply.
Keep on Trucking
An Expires header can also be used to extend an existing registration or subscription. Let’s say that a SIP User Agent sent a Register with an Expires header containing the value of 86,400. 86,400 seconds equates to 24 hours. To ensure that the registration remains in force after 24 hours, the SIP User Agent must send another Register sometime prior to the expiration of the first with a new Expires header of 86,400. This extends the registration an additional 24 hours. The SIP User Agent will continue to send Register messages until it’s ready to shutdown. At that point it sends a Register containing an Expires header with the value of 0 (zero). This will cancel the previous registration. Again, Subscribe works the same way.
That’s pretty much it for SIP timers. T1, Timer B, and Timer F ensure that messages arrive and the Expires header gives duration to specific SIP operations. Are you starting to feel a little more like a SIP guru? If not, stick around. I have lots more to talk about.
Tao, Zen, and Tomorrow 
expires header explanation is not correct. Expires is for the length of the time, for which , the registration or the invite session will be active. It has nothing to do with the response timeout.
Thank you for your comment, but I disagree. According to RFC 3261 section 13.3.1 Item 1:
1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated.
As I wrote, if a final response (e.g. 200 OK) has not been sent when the timer pops, the INVITE will be canceled (i.e. 487). Expires does not define how long a session will be active.
Andrew is correct Expire header has relationship with response.
The Expires header field is used to indicate the time interval in which the request or message contents are valid.
When present in an INVITE request, the header field sets a time limit on the completion of the INVITE request. That is,the UAC must receive a fi nal response (non-1xx) within the time period or the INVITE request is automatically canceled with a 408 Request Timeout response.
Hi,
I disagree with Andrew and mangnus,
As per RCC4028, Session Expires field signifies that the time at which an element will consider the session timed out, if no successful session refresh transaction occurs. This implies, if SE time is 1800 second then UAC must refresh session by sending UPDATE. Please correct me if i am wrong.
Yes, you can send an UPDATE, but I don’t see how that negates what I said about the session timing out. If nothing occurs, the session will time out if not established within the expires time frame.
@Sadanand Khedkar – the Session-Expires header (RFC 4028) has nothing to do with the Expires header. They are two different things.
What is the difference between use of exponential back off and expires header? Which one of them SIP uses to fire timeout? I read sip timers part 1 and part 2 both. I do not understand which of the “Exponential backoff” and “expires header” is used to fire timeout
Shantanu, the value in an expires header is a singular value that counts down to zero. There is only value and it’s not reset. Exponential back-off is a series of values. In the case of Timer-B, the timeouts start at T1 and progressively double until Timer-B is reached (by default, 64 times T1). Expires is used to determine the maximum time that something will exist. For example, Expires in a REGISTER is used to determine when registration expires. Exponential back-off is used to send retransmissions when the appropriate response is not received.
Reblogged this on telconextgen and commented:
good explanation
Hi Andrew – after reading your SIP timers (I & II) , I have a query to get clarify from you.
Suppose a SIP INVITE is sent to a SIP receiver and following are set –
1. T1 = 500 ms and Timer B/F set to 4 seconds .
2. Also , the EXPIRE timer set in INVITE message is some value greater than Timer B/F (lets say 60 min)
Now , If SIP UA does not receive a response for INVITE sent , i believe that SIP INVITE will be sent 5 times untill 4 seconds (Timer B = 4 sec) after the 1st INVITE sent at T=0 sec . after this last 5th INVITE , and no response received , the SIP UA will get the Request timed out (408) , generated by the SIP stack itself .
now my query is – even though the EXPIRE timer (60 mins) is set in INVITE message sent , and in the event of no response received , the INVITE is getting cancelled after 4 seconds only .
so , what is the significance of setting EXPIRE timer in INVITE message and how it will take precedence when above SIP network layer Timers are set .
Thanks
Manish T
Manish,
Timer-B only applies if no response is received for the INVITE. Once any response is received, Timer-B is out of the picture. The Expires header is completely independent and is used to determine how long the INVITE is valid after the UAC knows that someone is processing it (i.e. some response has been received).
Does this make sense? They are two separate timers used for two separate things.
Thanks Andrew for a quick response.. So If I understand correctly , the Expire header is invoked only when 1xx (TRYING) response has been received to INVITE request ( for e.g).
If my above understanding is correct , then consider a scenario , where UA is only expecting a non 1xx response
( for e.g.; consider a scenario where SIP INVITE is sent to SIP server to check the number portability resolution for a mobile number) , and where the response expected is not 1xx , but something like 302 (temp moved) or 404 (not found) from the SIP server.
now my question is – If no response is received to my INVITE in the above scenario, after 4 seconds (Timer B) , then is there any use of defining EXPIRE header in my INVITE request , for above specific (non call scenario) case.
It does not matter what response is received. Any response (100, 302, 404, etc.) will stop Timer-B. If no response is received, then Timer-B takes precedence over anything in an Expires header. So, if all you want is a 302 or 404 and you are sending directly to a redirect server, there is no good reason to set an Expires header.
I think of an Expires as a way to stop ringing and you aren’t trying to do that in your case.
yes .. Thanks a lot ..now crystal clear to me.. wish you many thanks for your blogs and comments ..
by the way – jz to introduce myself on a pleasant gesture , I am working on the product development side in TATA communications and currently preparing high level requirements for developing a SIP gateway (UA), which will perform the number portability resolution for the Mobile Number , from a SIP server.
the SIP flow from UA–>SIP number portability check server will be something like this –
INVITE sent
INVITE sip:90223333333@tata.com SIP/2.0.
MESSAGE received
SIP/2.0 302 Moved Temporarily
Contact: sip:123490223333333@ip add of domain.com
——————————————————————-
I have a couple of few more questions , if you may allow please,
1. Can we configure both TCP and UDP SIP listeners together on a SIP server –
2, If yes , and If I need to send SIP messages on TCP transport , do there is any changes in SIP URI and any related parameters in INVITE messages
1. You would need a SIP stack that can handle that, but there is no reason why you can’t do both on one server.
2. Any header that specifies the transport will have to reference TCP. The VIA header and possibly the Contact header come to mind. For example:
Via: SIP/2.0/TCP 10.101.6.120;branch=z9hG4bKf_169eac12baa17054e0adfb3_I
Thanks once again Andrew..for the timely help
Hi Andrew , Can you please send me some examples for SIP response message with the status code 488 as i am confused in understanding as what could cause this response .
Thanks in advance
The only time I’ve encountered a 488 was when the UAS didn’t like the SDP it received. One example was too many codecs. The UAS could only process upwards of 10 codecs and the UAC was sending 25. I dropped the number of codec and the problem disappeared. I’ve also heard that a 488 will be generated when badly formatted SDP is received.
I hope this helps.
I just remembered that I wrote about it here: https://andrewjprokop.wordpress.com/2014/05/19/finding-and-fixing-sip-and-voip-problems/
Hats off Mr Andrew…It is my first visit in your blog.. but the way of your reply for every question really motivated to me go in depth of SIP.
May God bless you always…
Hi Andrew,
What about re transmission from Proxy. suppose A is sending Invite to B but there are two Proxi between them so in that case if a is getting 100 trying from Proxy P1 but Proxy P1 is not getting any respose from P2 how p1 will re transmit request…….any timer….
Regards,
Navneet
Each user agent client that sends the INVITE will have its own timer. If one of the timers pops before a response is received, the proxy will generate a 408 Timeout response.
Hello Andrew,
regarding the below query,. the P1 will resend the INVITE ? am not fully getting it.. plss
Hi Andrew,
What about re transmission from Proxy. suppose A is sending Invite to B but there are two Proxi between them so in that case if a is getting 100 trying from Proxy P1 but Proxy P1 is not getting any respose from P2 how p1 will re transmit request…….any timer….
Regards,
Navneet
Navneet, every SIP entity can have its own set of timers. When an endpoint sends an INVITE to a proxy it will use Timer-B. Also, that proxy will have its own Timer-B. In other words, every element that sends a SIP request will maintain its own set of timers.
Hi Andrew,
I was looking for a solution when I came across your site. The issue I’m facing is that I have an endpoint that registers with an expires=1800 and a server that ignores that interval and expects any registration expiration of 300. I was told our SBC (Audiocodes Mediant 4000) couldn’t compensate for these two different timers (ie. handles the registration on behalve of the UAS and keeps two independant timers for registration). Do you know if this can be solved in any way other than having both vendors change there software (endpoint and server vendors that is).
Thanks and best regards,
David
David, when your clients sends an Expires of 1800 does the server send a 200 OK with an Expires of 300? That is a legal situation and the client needs to realize that it’s requested time was not honored.
And here is me researching some problems some clients are having with loosing sound during conversations and transfers. Hey David, some time no see! Andrew, what happens when the timer expires?
Yes correct. Thing is, the ‘client’ is actually a GSM provider network where the clients are the cell-phones. Registration timer in the network is fixed because of network load, hence the need for some sort of proxy that handles different timings. I’m not sure about the SBC, since the manual talks about an option with different registration timers and it allmost works; the client registers with it’s timer of 1800 and the SBC registers at the server with 300. After 300 sec the SBC sends a new register to the server which responds with a 200OK, but the SBC for some reason still clears the registration. To me that seams like a bug, but Audiocodes tells me that it shouldn’t work at all (without further explanation).
Also, what would the ‘client’ do in this situation? Simply accept the lower value of 300 or is there some reply that would indicate that a higher value is required?
David…the client has to accept what the server decides. There is no negotiation process other than sending another REGISTER, but I expect that the server will respond with the same Expires.
Let me ask my buddies at AudioCodes if they have an answer for you. Stay tuned.
Hi Andrew,
Thanks for your reply and your offer to check with Audiocodes. I also have a GRIP request pending with Avaya since the server in question is an IPOffice; it should accept the proposed 1800 but apparently doesn’t and there are no params to set. It does work fine with our CM and SM combination. I’m a bit stuck here especially since the answer from Audiocodes is a little unsatisfactory; my local Audiocodes engineer cannot get past his contact in France and escalate to Israel for R&D for a more firm answer.
Let’s hope you have more luck and thanks again!
David, send an email to ajprokop@gmail.com. I have some information to exchange with you.
Hello Andrew,
I have a question. I am trying to get the answer from above blog. Still not clear.
My scenario is I am sending a Invite req to Radisys MS[Empty invite – late SDP].
I set Expires header to 45 or anything huge value.
When MS sends 200OK with his SDP, I am trying to establish peer leg by sharing MS SDP in Invite.
But in some scenario since I do not get any response from peer leg in 32 sec, I wont be able to send ack+sdp to MS.But the MS sends few 200OK and them time out happen after 32 sec.
Here as per your answer for a similar question above, my Expire header [in the INVITE sent to MS] should have taken precedence. it is more than 32 sec. Any idea why it dint work? Am I missing something here?
Mahesh
I am a little unclear as to what you are saying. Does your client receive the 200 OK(s)? Does it then attempt to send an ACK that seems to be ignored? If an ACK is not received by the UAS it will time-out.
So, are messages being lost?
yes. my uac client receives 200OK with SDP. I exchange this sdp with peer leg. But the peer leg does not pick up the call. it keeps ringing So I wont be able to exchange his sdp with Media Server. So he[MS] keeps sending 200OK till 32 sec and then terminates the session with Bye.
Add on to the above explanation, session-expires in the 200OK sent from MS is “36000”.
But it waits only for 32 sec.
It’s really hard for me to say what is going on. I would look at the ACK to ensure that it has the right Call-ID and To and From tags. Is there any way to do a packet trace to see if it arrives at the UAS? It is either not showing up or it doesn’t like what it sees.
Sorry. I think I think I failed to explain you.
I have an app server. I create a callLeg with Media server like this.
I send MS a empty Invite[without SDP. ie late SDP]
And I get his 200OK with SDP
I create another leg[say for eg peer leg] with the above SDP.
And I dont get his SDP. So I wont be able to send SPD to MS in 32 sec.
So MS keeps sending 200OK till 32 sec and then sends BYE.
My question is can I do something[other than session refresh] so that MS does not send BYE in 32 sec?
what is the minimum and maximum time limit for a register message ?
I don’t know of any defined limits. In my experience, the SIP Registrar will have its own limits, but that is defined by implementation and not protocol.
Hi Andrew,
I am trying to register my endpoint line. But when the endpoint send SIP REGISTER Request, it doesn’t reach at server side. What may be the issue.(Using Best codec value and there is no firewall)
Does it not get there or is it not processed? Could this be an authentication error? Did you trace it with Wireshark? It’s hard to know what is happening without a trace.
There are no codecs in a REGISTER so that can’t be the problem.
Actually i mirrored all WAN traffic to my machine’s LAN port and i captured the traffic there with “SIP” as filter(to capture only sip packets), What i saw is that Register request is sending out there, But i didn’t see any “authentication response” in response to REGISTER Request,
Then i also checked at server side to check whether the request is reaching or not? But what is find is nothing, means the request is not reaching at server.
NOTE:
All the things is happening when i disconnect and connect wan cable back.(Before disconnecting the wan cable all things is fine, means line are successfully registered). After doing this i expect that lines will be registered once WAN connection comes up.(WAN comes successfully )
Sounds like a network or IP stack problem. I’m not sure what else I can say.
Hi Andrew,
I am a little bit confused about Expires header in INVITE and Non-INVITE requests.
1) A ——-INVITE (Expires:60)——————————————-> B
2) A <—————180 ——————————————————-B
Now assume that , 60 secs in Expires got fired
Q1) Will B send "408 Request time out" or will A send "CANCEL" to which it will reply with 487 Dialog/ request terminated ? (Here whether the server or client should take the action)
Also how does this work in case of NON INVITE requests?
A will send the CANCEL.
Each non INVITE case needs to be considered separately. Give me an example of what you are thinking about.
In the last comment , I meant A sends CANCEL for which B sends 200 OK and 487 for the INVITE
Hi Andrew, I have a phone thought which a call is established easily, but the call drops exactly after ten minutes. Do you think that one of these timers has been configured incorrectly in the ATA?
Could be. Are you getting a SIP response message when the call drops?
What would cause an INVITE to be sent out 5 times without receiving a response? I’ve been stuck on this issue for a while.
A broken server. A malformed packet. Network issues. Any of these would cause your problem.
Hi Andrew, Helpful article!
We are having an issue with a client where some BYE messages aren’t being received by a PBX (we’re still investigating why) and therefore the PBX is holding the call active forever (until the PBX is rebooted.)
Are there established standards for how long a call should sit before another SIP dialog should occur in order to be considered still an active call? Does the spec call for a keepalive type message be sent every so often and the lack of response should prompt the PBX to end the call? I get that we need to find the cause of these missing BYE messages, but I’m trying to prove that a PBX shouldn’t sit with a call in limbo forever either.
A BYE requires a 200 OK. If the 200 OK is not received, the BYE will be resent. If it’s never received (after the appropriate timeout), the sender will shut down its end of the call. I suspect that the other end would recognize that either a socket was closed or media was no longer received. However, it appears that that’s not happening in your case.
Yes, the telco switch is sending the BYE and not getting an response, so the telco switch is ending the session. However, the PBX is waiting for a BYE that it’s never receiving… so I’m wondering if there is any other type of keepalive or timer that should expire from a lack of messaging that would prompt the PBX to end the call.
I can’t think of anything. I would hope that the closed socket would be enough.
Very nice article. I would like to know if the SIP timers work only for the SIP messages going on UDP or the timers work both for UDP and TCP?Please clarify.
Hi Andrew,
Can you tell why CANCEL IS OUT-OF-DIALOG
Hi Andrew,
I hv a question.
Suppose in between two end point A & B there are TWO SBC i.e. Sbc1 & Sbc2.
when A sends a INVITE messsage to B via these Two SBC, what are the value got changes in parameter level when a Packet goes from SBC1 to SbC2?
Note :BOTH SBC are deployed on same Network.
Thanks,
Rupak
Thank your for the great article. very well explained
I see Expires header in REGISTER message but not in INVITE
Where can I see the timer values then? Are they contained in SDP?
There is no requirement that an INVITE has an Expires header.
The basic timers are inherent in the protocol itself. They are not carried in the SDP.
1) let say Invite is retransmitted multiple times and timer B fires. What message is sent now to complete the transaction?
2) When is 408 response sent?
hi, can u clarify the above to me plzz. 🙂
Hello Dear Andrew,
Can you include on this article information about Min-SE field?
Thanks in advance for your attention.
Best Regards
Angel
Greetings SIP Brotherhood, had one issue with update,
A->me->B
A invite expires 3600, Min-SE:600
our sbc sent update on 15min to both parties, calls drop from A, seems not understand UPDATE?
Hi Andrew, Can you explain one thing regarding register request,Gives a response 401 unauthorized, If The 401 is not matched with UA side then at how much interval it will send a register request & what will happen in the end??
One Query :- If a SIP is registered at PBX with 300s.But after 60s ,SIP Terminal
send a REGISTER with Expires header with 60s value, will Server need to deregister SIP