cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
14289
Views
20
Helpful
6
Replies

SIP trunk keepalives using re-invites

matigil
Level 1
Level 1

From a Cisco router running as CUBE I am able to send keepalives using SIP-OPTIONs message.

Can I enable a Cisco gateway to generate SIP re-INVITE messages as keepalives over a SIP trunk?

3 Accepted Solutions

Accepted Solutions

The SIP Session Timer Support feature adds the capability to  periodically refresh Session Initiation Protocol (SIP) sessions by  sending repeated INVITE requests. The repeated INVITE requests, or  re-INVITEs, are sent during an active call leg to allow user agents (UA)  or proxies to determine the status of a SIP session. Without this  keepalive mechanism, proxies that remember incoming and outgoing  requests (stateful proxies) may continue to retain call state  needlessly. If a UA fails to send a BYE message at the end of a session  or if the BYE message is lost because of network problems, a stateful  proxy does not know that the session has ended. The re-INVITES ensure  that active sessions stay active and completed sessions are terminated.

The SIP Session Timer Support feature also adds two new general headers  that are used to negotiate the value of the refresh interval.

A Session-Expires header is used in an INVITE if the user agent client (UAC) wants to use the session timer.

The Minimum Session Expiration (Min-SE) header conveys the minimum allowed value for the session expiration.

Define a Min-SE on your cisco gateway with these commands:

Router(config)# voice service voip
Router(conf-voi-serv)# sip 
Router(conf-serv-sip)# min-se 300


Defaults

1800 seconds




Regards.

View solution in original post

Yes, your analysis is right. The other end sip party doesn't support timer option.

The support of RFC4028 is not mandatory.

Regards.

View solution in original post

amiobero
Cisco Employee
Cisco Employee

I have looked into the issue and see that as per the restrictions of SIP

session timer feature Cisco SIP gateways cannot initiate the use of SIP

session timers, but do fully support session timers if another UA requests

it. This I guess if we don't see the "Session-Expires" field in SIP invite

sent from the Gateway as opposed that sent by CUCM, it is normal.

 

In fact the "supported" filed in SIP invite/2xx message from gateway shows

as below

 

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

 

Presence of timer as an option confirms that it will support SIP session

timer feature. See the URL below for more details.

 

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb_1369_p

s5640_TSD_Products_Configuration_Guide_Chapter.html 

 

Instead we should see the session expires with refresher parameter in the

2xx (200 OK) message from the gateway to CUCM.

 

Now as far as your call scenario is concerned, in what direction are you

making the call? Can you please explain me the call flow as depicted

 

IP Phone>Gateway>SIP Trunk>CUCM>IP Phone.

 

I would assume that if the call is initiated from the Gateway side, it might

not support session timer as gateway will not initiate it.

View solution in original post

6 Replies 6

The SIP Session Timer Support feature adds the capability to  periodically refresh Session Initiation Protocol (SIP) sessions by  sending repeated INVITE requests. The repeated INVITE requests, or  re-INVITEs, are sent during an active call leg to allow user agents (UA)  or proxies to determine the status of a SIP session. Without this  keepalive mechanism, proxies that remember incoming and outgoing  requests (stateful proxies) may continue to retain call state  needlessly. If a UA fails to send a BYE message at the end of a session  or if the BYE message is lost because of network problems, a stateful  proxy does not know that the session has ended. The re-INVITES ensure  that active sessions stay active and completed sessions are terminated.

The SIP Session Timer Support feature also adds two new general headers  that are used to negotiate the value of the refresh interval.

A Session-Expires header is used in an INVITE if the user agent client (UAC) wants to use the session timer.

The Minimum Session Expiration (Min-SE) header conveys the minimum allowed value for the session expiration.

Define a Min-SE on your cisco gateway with these commands:

Router(config)# voice service voip
Router(conf-voi-serv)# sip 
Router(conf-serv-sip)# min-se 300


Defaults

1800 seconds




Regards.

Thanks Daniele,

in fact I tested this command but I didn't see any re-invite after 300 s.

Then I went deeper in the RFC 4028, and I realized that the problem was at the other end.

According to this RFC, there must be a negotiation, but the other end didn't send the timer option flag on. So I guess Cisco router didn't enable SIP session timer as it was not negotiated:

Cisco 2811 sent:


INVITE sip:xxxxxxxxx@10.35.133.7:5060 SIP/2.0
Via: SIP/2.0/UDP 10.35.133.3:5060;branch=z9hG4bKD0D16DA
Remote-Party-ID: "Mati Gil" <550012037>;party=calling;screen=yes;privacy=off
From: "Mati Gil" <550012037>;tag=291CC694-1BC6
To:
Date: Thu, 17 Mar 2011 11:35:52 GMT
Call-ID: 8C6AC335-4FC111E0-A268F89A-16BE1A5E@10.35.133.3
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2355606997-1338053088-2724395162-381557342
User-Agent: Cisco-SIPGateway/IOS-12.x
Accept-Language: es
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1300361752
Contact: <550012037>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 244

v=0
o=CiscoSystemsSIP-GW-UserAgent 7480 3143 IN IP4 10.35.133.3
s=SIP Call
c=IN IP4 10.35.133.3
t=0 0
m=audio 17592 RTP/AVP 8 101
c=IN IP4 10.35.133.3
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

*Mar 17 12:35:52: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.35.133.3:5060;received=10.35.133.3;branch=z9hG4bKD0D16DA
Call-ID: 8C6AC335-4FC111E0-A268F89A-16BE1A5E@10.35.133.3
From: "Mati Gil" <550012037>;tag=291CC694-1BC6
To:
CSeq: 101 INVITE
Content-Length:  0

Response from the other end (non-cisco SIP end), with no "timer" supported option:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.35.133.3:5060;received=10.35.133.3;branch=z9hG4bKD0D16DA
Call-ID: 8C6AC335-4FC111E0-A268F89A-16BE1A5E@10.35.133.3
From: "Mati Gil" <550012037>;tag=291CC694-1BC6
To: ;tag=fku04aMfVVEa4AC3A0LPYA1VhKh4T-cr
CSeq: 101 INVITE
Contact:
Allow: SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK
Supported: 100rel
Content-Type: application/sdp
Content-Length:   203

v=0
o=- 3509350377 3509350378 IN IP4 10.35.133.7
s=ulnar
c=IN IP4 10.35.133.7
t=0 0
m=audio 7006 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

What I don't see on INVITE message is the Session-Expires value. Is it mandatory? I find it when the invite comes from a Call Manager. Anyway, the other end doesn't seem to be RFC compliant.

Regards

matigil
Level 1
Level 1

Sorry,

I have attched the SIP Invite that initially comes from a Call Manager. The SIP INVITE that comes from the Cisco Gateway, where "session expire" is missing,  is

Sent:
INVITE sip:xxxxxxxxx@10.35.133.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.35.133.2:5060;branch=z9hG4bK9525AA
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
From: ;tag=2915F0AC-5C0
To:
Date: Thu, 17 Mar 2011 12:07:37 GMT
Call-ID: FBED7052-4FC511E0-9A56ABC6-77F3852E@10.35.133.2
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  300
Cisco-Guid: 4226441970-1338315232-2163736601-1447633104
User-Agent: Cisco-SIPGateway/IOS-12.x
Accept-Language: es
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1300363657
Contact:
Expires: 180
Allow-Events: telephone-event
Cisco-Gcid: FBEA62F2-4FC5-11E0-80F8-0019564920D0
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 244

v=0
o=CiscoSystemsSIP-GW-UserAgent 4792 7274 IN IP4 10.35.133.2
s=SIP Call
c=IN IP4 10.35.133.2
t=0 0
m=audio 16518 RTP/AVP 8 101
c=IN IP4 10.35.133.2
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Yes, your analysis is right. The other end sip party doesn't support timer option.

The support of RFC4028 is not mandatory.

Regards.

amiobero
Cisco Employee
Cisco Employee

I have looked into the issue and see that as per the restrictions of SIP

session timer feature Cisco SIP gateways cannot initiate the use of SIP

session timers, but do fully support session timers if another UA requests

it. This I guess if we don't see the "Session-Expires" field in SIP invite

sent from the Gateway as opposed that sent by CUCM, it is normal.

 

In fact the "supported" filed in SIP invite/2xx message from gateway shows

as below

 

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

 

Presence of timer as an option confirms that it will support SIP session

timer feature. See the URL below for more details.

 

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb_1369_p

s5640_TSD_Products_Configuration_Guide_Chapter.html 

 

Instead we should see the session expires with refresher parameter in the

2xx (200 OK) message from the gateway to CUCM.

 

Now as far as your call scenario is concerned, in what direction are you

making the call? Can you please explain me the call flow as depicted

 

IP Phone>Gateway>SIP Trunk>CUCM>IP Phone.

 

I would assume that if the call is initiated from the Gateway side, it might

not support session timer as gateway will not initiate it.

The scenario is

Phone->PSTN networks->PRI ISDN E1 port->Gateway->SIP Trunk -> Third party SIP ACD

It seems the ACD does not respond with the apropiate timer options.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: