[SIPForum-discussion] Reg : Issue with 40 min call disconnection

Ronald del Rosario rrosario at five9.com
Thu Nov 11 16:58:48 UTC 2010


This is the best explanation so far on this topic about Session Timers.

 

Also, on the Internet Telephony Service Providers (ITSP) perspective,
Session Timers helps us keeps track of "run-away" calls, zombie calls,
etc.  and not get billed when we connect with other entities using SIP
Trunking. 

 

When working on a SIP Trunking project, you need to ensure that the
other ITSP you are working on supports Session Timers.

 

Ron

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Karthik Ramiya
Rengarao (kramiyar)
Sent: Thursday, November 11, 2010 2:39 AM
To: Sathya; Garron, James; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Reg : Issue with 40 min call
disconnection

 

Session timer is a way of audit mechanism implemented in the protocol to
release unused resources in a network element.

 

Say for eg. When a call originates from A to B via a network element X .
For some reasons if the call is terminated at B which due to some
network failure where A didn't get the BYE for it. Call state at A would
remains the same without knowing the termination at B. Resources
allocated for that particular call would be in a unused state. 

 

Session refresh mechanism is implemented to avoid these scenarios
wherein after session establishment if there is no session refresh
handshake between the two at proper interval call would get disconnected
and resources cleared.

 

Hope this helps.

 

Cheers,

Karthik

 

 

 

 

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Sathya
Sent: Wednesday, October 27, 2010 11:21 AM
To: Garron, James; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Reg : Issue with 40 min call
disconnection

 

Hi,

 Thanks for your reply.

 The call flow is as follows

 Origination device  ------>  SBC -------> Destination SBC.

Suppose if  there is no Re-Invite after half of the time of session
expiry then what will happen to the ongoing call .. will it get
disconnected if yes at what time.

If session expiry is not mandatory on a sip call then what is the actual
use of this parameter.

Kindly clarify.

Regards

Sathya.



On Wed, Oct 27, 2010 at 1:22 AM, Garron, James <jgarron at sonusnet.com>
wrote:

Inline

 

________________________________

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Sathya
Sent: Tuesday, October 26, 2010 6:13 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Reg : Issue with 40 min call
disconnection

 

Hi All,

    I have come across one issue wherein the sip call gets disconnected
within 40 minutes from the destination end. Also found that the issue
was due to no session expiry parameter was set in the originating
device.

Kindly clarify

1. If the originating device has no settings ( fields ) for minimum
session expiry then will the SBC automatically refresh the session.

 

SBC can send a re-INVITE to the originating device even if session
expiry was not sent, but can not expect the originating device to send
one as it did not advertise that it could/would.


2. If 3600 is the session expiry time then at what time the re-invite
should generate to refresh the session and which end should generate the
re-invite ( Source or destination ).

 

If the session expiry is set to 3600 you should expect that the
re-INVITE will be sent at half this duration or 1800 (15 mins).  This is
to ensure that the other end has time to respond.  The device that sends
the re-INVITE is negotiated using refresher=uac (or uas).


3. Is the session expiry and min session expiry settings is mandatory on
a sip call.

 

No, they are not mandatory.



Kindly clarify the above points

Thanks

Sathya.



     

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20101111/df084a0f/attachment-0002.html>


More information about the discussion mailing list