IMG 1010 - Media Inactivity Timers (RTP)
Initial Media Inactivity Timer / Media Inactivity Timer
Supported on both Mindspeed and BroadComm VoIP Module
Supported in both SIP and H.323 Signaling
Overview:
The Media Inactivity feature was added to the IMG to inform the signaling layers (SIP and H323) when RTP has stopped flowing. The Initial Media Inactivity timer indicates that no RTP was ever received on the IP channel. The Media Inactivity Timer indicates that RTP has stopped flowing. When the signaling layers receive indications that these timers have expired, the signaling releases the channel. This feature resolves the problem where signaling gets out of sync and IP channels remain up with no one on the other side of the call.
Initial Media Inactivity Timer:
The Initial Media Inactivity Timer was added in software 10.5.0 ER1. This timer is started when the channel is setup (Outseized). If no RTP packets are received for the configured amount of time, an event is generated to the signaling layers. The Default value for the Initial Media Inactivity Timer field is Disabled. To Enable the Initial Media Inactivity Timer, click in the Initial Media Inactivity Timer field and select Enable. When you Enable the Initial Media Inactivity Timer field, another field, "Initial Media Inactivity Timer Value" will appear just below it. This field will allow configuring a value in seconds to this timer.
Media Inactivity Timer:
The Media Inactivity Timer was added in software 10.5.0 ER1. This timer is used to indicate that RTP packets have stopped flowing for the configured amount of time. When RTP packets stop flowing for the configured amount of time, an event is generated to the signaling layers and the signaling releases the channel. The Default value for the Media Inactivity Timer field is Disabled. To enable the Media Inactivity Timer, click in the Media Inactivity Timer field and select Enable. When you Enable the Media Inactivity Timer field, another field , "Media Inactivity Timer Value", will appear just below it. This field will allow configuring a value in seconds to this timer.
The Media Inactivity Timer (MID) will not be started until initial RTP incoming traffic is observed by the VoIP channel. The Initial Media Inactivity Timer (IMID) must be used to inform the signaling layers if no initial RTP incoming traffic is observed in the defined IMID time.
The Initial Media Inactivity Timer and Media Inactivity Timers also take into account if a call is put "ON HOLD" or if a call is put into a XMT only or RCVonly mode. The table below displays what happens in each of the cases.
Call Placed "ON HOLD" | When a call is placed ON HOLD, the IMG will automatically disable the Initial Media Inactivity Timer and the Media Inactivity Timer. Since no packets are being sent and possibly not received during the ON HOLD session, the Timers must be disabled to ensure that they do not release the channel. |
Last Packet was a Silence Packet (I.E. Go Mute on a conference call) | If the last packet sent to the IMG is a silence packet indicating the call has entered into a period of silence, then the Media Inactivity Timer will not be active during this silence period. When RTP packets start flowing again, the call is taken "OFF MUTE", the timer will be reactivated |
Call is in XMTonly. (I.E. Waiting for a response to a 183 Call Progress) | If the call is put into a XMTonly mode during the Progression of the Call, the Initial Media Inactivity Timer and Media Inactivity Timer will be disabled. |
Call is in RCVonly. ( I.E Waiting for a response to a 183 Call Progress) | If the call is put into a RCVonly mode during the Progression of a Call, the IMG disables the transmitting of RTP and RTCP packets. The Initial Media Inactivity Timer and Media Inactivity Timer are not altered during this mode since the channel should be receiving RTP packets. |
Configuration:
The Initial Media Inactivity Timer and the Media Inactivity Timers are both configured through the IP Bearer Profile Object Pane in ClientView. Within this pane you can enable the Initial Media Inactivity Timer and Media Inactivity Timer. See screen captures below. The Default in ClientView is they are both initially Disabled.
Once enabled, a second Initial Media Inactivity Timer Value field will be displayed below each of the timers. See Below.
Click in either the Initial Media Inactivity Timer Value or the Media Inactivity Timer Value field and a Range Dialog Box will appear. The Range Dialog Box allows you to configure the amount of seconds for each Timer. Below is screen capture of both the Initial Media Inactivity Timer Value Range Dialog Box and the Media Inactivity Timer Value Range Dialog Box. To change the Value in Seconds simply slide the Range Bar left or right to the desired value.
Depending on the Network conditions, setting the Initial Media Inactivity Timer or Media Inactivity Timer to a low value may cause calls to release before they have completely established.
Range Dialog Box Settings for Initial Media Inactivity Timer Value and Media Inactivity Timer Value
| Default Value (seconds) | Configurable Range (seconds) |
Initial Media Inactivity Timer Value | 181 sec (3 Min 1 second) | 1 to 655 seconds (10 Min 55 seconds) |
Media Inactivity Timer Value | 30 sec (1/2 Min) | 1 to 60 seconds |
Once the timers are configured and the profile is committed, both Initial Media Inactivity Timer and Media Inactivity Timers are set for all new calls using this profile.
Call Flows:
Below are a few Call Flows and what would happen if the Initial Media Inactivity Timer or Media Inactivity Timer were to expire and send the message to the signaling layer to release the Channel
Call Flow Example 1: (SIP)
When the Initial Media Inactivity Timer expires it sends a message to Layer 3 Signaling to initiate a tear down of the call. A BYE is sent to the Gateway and a Clear Request is sent to Layer 4 to release call.
Call Flow Example 2: (H.323)
When the Initial Media Inactivity Timer expires it sends a message to Layer 3 Signaling to initiate a tear down of the call. A Release Complete is sent to the Gateway and a Disconnect Request is sent to Layer 4 to release call.
Call Trace:
Below is and example of a G.723 to G.729 SIP Call. The Initial Media Inactivity Timer expired and sent the information to tear down the channel and any network resources. The Call trace below does not have the complete call. It is a portion of the Call Trace which shows what the Initial Media Inactivity Timer. The call is initially connected as shown below.
11:48:25.620 CALL(SIP) (02:00008:00) RCVD Cut Thru from VPPL
11:48:25.620 CALL(SIP) (02:00008:00) RCVD Connect from VPPL
11:48:25.640 CALL(SIP) (02:00008:00) RCVD ACK from 10.129.44.36:5060 UDP CSeq:1
Msg Size:352
11:48:25.640 CALL(SIP) (02:00008:00) with Via sent-by: 10.129.44.36 UDP
11:48:25.640 CALL(SIP) (02:00008:00)
---> [10.129.44.36, 5060]
ACK sip:1111@10.129.44.37:5060 SIP/2.0\r\n
Via: SIP/2.0/UDP 10.129.44.36:5060\r\n
From: 8340 <sip:8340@10.129.44.36:5060>;tag=1\r\n
To: sut <sip:1111@10.129.44.37:5060>;tag=a94c095b773be1d
d6e8d668a785a9c84ec379461\r\n
Call-ID: 1-3132@10.129.44.36\r\n
Cseq: 1 ACK\r\n
Contact: sip:sipp@10.129.44.36:5060\r\n
Max-Forwards: 70\r\n
Subject: Performance Test\r\n
Content-Length: 0\r\n
\r\n
11:51:26.710 CALL(IP) (02:00008:01) SENT Initial MID event to SIP (RTP never seen)
11:51:26.710 CALL(SIP) (02:00008:01) RCVD Initial Media Inactivity Timer Indication from VPPL
11:51:26.710 CALL(SIP) (02:00008:01) SENT BYE to 10.129.44.44:5060 Cseq:2
11:51:26.710 CALL(SIP) (02:00008:01) with R-URI: 10.129.44.44:5060 UDP
11:51:26.710 CALL(SIP) (02:00008:01)
<--- [10.129.44.44, 5060 <- 10.129.44.37, 5060]
BYE sip:10.129.44.44:5060 SIP/2.0\r\n
Via: SIP/2.0/UDP 10.129.44.37:5060;rport;branch=z9hG4bK-
4b4d-147086-19988-118\r\n
Call-ID: 238d-407-021970164825-Sheridan-2@10.129.44.37\r
\n
CSeq: 2 BYE\r\n
Max-Forwards: 0\r\n
To: <sip:1111@10.129.44.44:5060>;tag=1\r\n
From: <sip:8340@10.129.44.37>;tag=95ffcd055e0f78f7d5d397
020e89288d0fc6cf04\r\n
User-Agent: Cantata-SIP/10.5.0.189 Sheridan 2\r\n
Content-Length: 0\r\n
\r\n
11:51:26.720 CALL(SIP) (02:00008:01) RCVD 200 OK BYE from 10.129.44.44:5060 UDP
CSeq:2 Msg Size:355
11:51:26.720 CALL(SIP) (02:00008:01)
---> [10.129.44.44, 5060 -> 10.129.44.37, 5060]
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 10.129.44.37:5060;rport;branch=z9hG4bK-
4b4d-147086-19988-118\r\n
From: <sip:8340@10.129.44.37>;tag=95ffcd055e0f78f7d5d397
020e89288d0fc6cf04\r\n
To: <sip:1111@10.129.44.44:5060>;tag=1;tag=1\r\n
Call-ID: 238d-407-021970164825-Sheridan-2@10.129.44.37\r
\n
CSeq: 2 BYE\r\n
Contact: <sip:10.129.44.44:5060;transport=UDP>\r\n
Content-Length: 0\r\n
\r\n
11:51:26.720 CALL(SIP) (02:00008:01) SENT L3-L3 Clear Req to VPPL
11:51:26.720 CALL(IP) (02:00008:01) RCVD Clear Request from L3P
11:51:26.720 CALL(IP) (02:00008:01) RTCP STATS: TxPackets=9055; RxPackets=0; l
ostPackets=0
11:51:26.720 CALL(SIP) (02:00008:01) RCVD Clear Req from VPPL
11:51:26.720 CALL(SIP) (02:00008:01) SENT Clear Request to L4
11:51:26.720 CALL(L4) (02:00008:01) RCVD Clear request from SIP
11:51:26.720 CALL(L4) (02:00008:01) SENT Channel Release w/data to GCL
11:51:26.720 CALL(GCL) (02:00008:01) RCVD Channel Released w/data, cause=16 fro
m L4
11:51:26.720 CALL(GCL) (02:00008:01) Call Duration(sec): 181
11:51:26.720 CALL(GCL) (02:00008:01) SENT Clear Call Request to GCL
11:51:26.720 CALL(GCL) (02:00008:00) SENT Park Port to L4
11:51:26.720 CALL(L4) (02:00008:00) RCVD Park from GCL
11:51:26.720 CALL(GCL) (02:00008:00) SENT Clear Response, cause=16 to L4
11:51:26.720 CALL(L4) (02:00008:00) RCVD Clear, cause=16 from GCL
11:51:26.720 CALL(L4) (02:00008:00) SENT Clear Request, cause=16 to SIP
11:51:26.720 CALL(SIP) (02:00008:00) RCVD Clear Request from L4
11:51:26.720 CALL(SIP) (02:00008:00) SENT BYE to 10.129.44.36:5060 Cseq:1
11:51:26.720 CALL(SIP) (02:00008:00) with R-URI: 10.129.44.36:5060 UDP
11:51:26.720 CALL(SIP) (02:00008:00)
<--- [10.129.44.36, 5060 <- 10.129.44.37, 5060]
BYE sip:sipp@10.129.44.36:5060 SIP/2.0\r\n
Via: SIP/2.0/UDP 10.129.44.37:5060;rport;branch=z9hG4bK-
4b3c-147086-19989-191\r\n
Call-ID: 1-3132@10.129.44.36\r\n
CSeq: 1 BYE\r\n
Max-Forwards: 0\r\n
To: <sip:8340@10.129.44.36:5060>;tag=1\r\n
From: <sip:1111@10.129.44.37:5060>;tag=a94c095b773be1dd6
e8d668a785a9c84ec379461\r\n
User-Agent: Cantata-SIP/10.5.0.189 Sheridan 2\r\n
Reason: SIP ;cause=16 ;text="Normal call clearing"\r\n
Content-Length: 0\r\n
\r\n
11:51:26.780 CALL(SIP) (02:00008:00) RCVD 200 OK BYE from 10.129.44.36:5060 UDP
CSeq:1 Msg Size:334
11:51:26.780 CALL(SIP) (02:00008:00)
---> [10.129.44.36, 5060 -> 10.129.44.37, 5060]
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 10.129.44.37:5060;rport;branch=z9hG4bK-
4b3c-147086-19989-191\r\n
From: <sip:1111@10.129.44.37:5060>;tag=a94c095b773be1dd6
e8d668a785a9c84ec379461\r\n
To: <sip:8340@10.129.44.36:5060>;tag=1;tag=1\r\n
Call-ID: 1-3132@10.129.44.36\r\n
CSeq: 1 BYE\r\n
Contact: <sip:10.129.44.36:5060;transport=UDP>\r\n
Content-Length: 0\r\n
\r\n
11:51:26.780 CALL(SIP) (02:00008:00) SENT L3-L3 Clear Req to VPPL
11:51:26.780 CALL(IP) (02:00008:00) RCVD Clear Request from L3P
11:51:26.780 CALL(IP) (02:00008:00) RTCP STATS: TxPackets=6037; RxPackets=0; l
ostPackets=0
11:51:26.780 CALL(SIP) (02:00008:00) RCVD Clear Req from VPPL
11:51:26.780 CALL(SIP) (02:00008:00) SENT Clear Request to L4
11:51:26.780 CALL(L4) (02:00008:00) RCVD Clear request from SIP
11:51:26.780 CALL(L4) (02:00008:00) SENT Channel Release w/data to GCL
11:51:26.780 CALL(GCL) (02:00008:00) RCVD Channel Released w/data, cause=16 fro
m L4
11:51:26.780 CALL(GCL) (02:00008:00) Call Duration(sec): 181
CALL>