Subject: [Sipping] [Fwd: Session Timers issue.]

From: Ramesh Ramamurthy <[email-masked]>
Date: Tue, 30 Mar 2004 09:04:43 -0700

-------- Original Message --------

Subject:

Session Timers issue.

Date:

Tue, 30 Mar 2004 08:57:47 -0700

From:

Ramesh Ramamurthy <[email-masked]>

Reply-To:

[email-masked]

Organization:

Verso Technologies Inc.

To:

[email-masked]

Hi all,
Reading the session timers draft I have two issues.
1. The delay in catching orphaned calls.
2. Tracking outage on a per call basis.
The session timer implementation is great for small endpoints with
limited number of calls. But there are serious performance consequences
when it comes to system with huge number of calls. Tracking calls from
a gateway that sends huge number of calls, say in 1000's, will be
stressful on the performance.
For this reason I suggest that we move away from a per call timer and
move to tracking the gateways.We have REGISTER messages which could be
used to tracks the outage at a gateway/endpoint level instead of on a
per call level.
Yes I agree, I am finding fault without suggesting a solution to the
problem. But I am only picking the collective brains behind the SIP
Protocol for a solution. To start out I would like to suggest on
possible solution that will keep track of the "uptime' of a given UAC
using the REGISTER message. If the "uptime" of a subsequent Register
message is less than or equal to that of current uptime, in the
UAS/Proxy, for the UAC we should clear all the calls belonging to that
UAC. In this implementation, I am assuming that REGISTERation is
compulsory which I know is false, but I am just starting a thread.The
advantage here is action is only taken when we recognize a problem,
instead of trying to scan for issues. The Uptime sent from the UAC to
UAS should include the bootup time and should include the date so that
we don't have a rollover issues.
I am new to this forum so forgive me if I am not following some set
procedure.

Cheers
Ramesh

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Mar 2004 10:59:30 -0600

Ramesh Ramamurthy wrote:

> used to tracks the outage at a gateway/endpoint level instead of on a 

The problem here is that, even if gateways registered (they don't), 
REGISTER messages may well never transit the call-stateful nodes that 
benefit from session-timer's mechanism for effecting state discard.

To make your approach work, I think each dialog-stateful element would 
have to SUBSCRIBE to the registration state (using the registration 
event package) for every UA involved in a dialog for which state is 
stored in that element. While this might generate an economy of scale 
for dialog-stateful elements servicing very large gateways (assuming 
they registered somewhere), it would be a huge expansion in overhead for 
smaller units, and most especially for single-user UAs like mobile phones.

Another issue here is that you are assuming fate-sharing between all 
dialogs associated with a large gateway. I suspect one cannot safely 
assume that because one call through a gateway has failed and can have 
its dialog-state purged that EVERY call going through that gateway is in 
the same condition.

A more efficient solution for your specific case would be to make the 
dialog-stateful element a back-to-back user agent. This would allow the 
dialog stateful element to use some out-of-dialog mechanism (periodic 
OPTIONS requests, SNMP, or other) to determine the status of the nodes 
for which it is holding state (has a dialog with), then issue a 
reINVITE, UPDATE, or BYE as appropriate for each dialog.

Of course, an even more efficient solution would be to not use 
dialog-stateful elements in the construction of services around large 
gateways, thereby completely preventing the situation from developing.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Ramesh Ramamurthy <[email-masked]>
Date: Tue, 30 Mar 2004 11:04:06 -0700

Thanks for the response reply is embedded.

Cheers
Ramesh
Dean Willis wrote:

>> limited number of calls. But there are serious performance 
>> consequences when it comes to  system with huge number of calls.  
>> Tracking calls from a gateway that sends huge number of calls, say in 
>> 1000's, will be stressful on the performance.
>> move to tracking the gateways.We have REGISTER messages which could 
>> be used to tracks the outage at a gateway/endpoint level instead of 
>> on a per call level.
>
>

I agree this will imply that the Gateways will have to support REGISTER. 
We could as well do it using Subscribe and Notify. the Subscribe and 
Notify could have the Uptime field and can be used to track the outage.

> they registered somewhere), it would be a huge expansion in overhead 
> for smaller units, and most especially for single-user UAs like mobile 
> phones.
>
Well the whole issue with orphaned call is a large gateway issue and not 
a big issue for small units. I am essentially splitting the states into 
two. One for the calls and another for Gateways/proxy as a whole. You 
will have to keep track of all the UA registered/subscribed to the 
service only. I am failing to understand how that could be a huge 
overhead. This will be like any other Subscriber/notify operation. The 
deciding factor is the "UPTIME" in the message which indicates whether 
there was a restart, which is the reason why we have orphans, of the 
peer. Please educate me if I am missing something.

> its dialog-state purged that EVERY call going through that gateway is 
> in the same condition.

The assumption here, which I should have explained, is that calls will 
be started only after the gateway subscriber to the feature. Upon 
subscription, looking at the uptime in the subscribe/notify method, a 
decision will be taken as to whether all calls associated with the peer 
need to be cleared or not. If the uptime from the peer is greater than 
what was previously sent then we decide not to clear the calls else we 
clear the calls from the peer.

> dialog-stateful element a back-to-back user agent. This would allow 
> the dialog stateful element to use some out-of-dialog mechanism 
> (periodic OPTIONS requests, SNMP, or other) to determine the status of 
> the nodes for which it is holding state (has a dialog with), then 
> issue a reINVITE, UPDATE, or BYE as appropriate for each dialog.

Well the issue is that we need something that is standardized under the 
SIP protocol . My intention was to get something like Session timer that 
everybody can use and be interoperable between vendor. I feel that we 
should separate the state of the call and the state of the gateway. This 
way the performance impact on large gateways is limited.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 30 Mar 2004 13:30:52 -0500

Ramesh,

Is the Subscribe with its timers to refresh subscriptions significantly 
less onerous than Session Timer?  You seem to be trading one type of 
problem for another.  Could not an adjustment of the timers achieve the 
desired reduction in load?

Also, I recall some discussion about devices being able to reboot and 
recover calls across that reboot.  The scheme you suggest would seem to 
preclude that, or at least trash such calls when a registration is younger 
than the call.

Not really addressing the problem, but may avoid "jumping from frying pan 
into the fire".

Mike

At 11:04 AM 3/30/2004 -0700, Ramesh Ramamurthy wrote:
>>>when it comes to  system with huge number of calls.
>>have to SUBSCRIBE to the registration state (using the registration event 
>>package) for every UA involved in a dialog for which state is stored in 
>>that element. While this might generate an economy of scale for 
>>dialog-stateful elements servicing very large gateways (assuming they 
>>registered somewhere), it would be a huge expansion in overhead for 
>Well the whole issue with orphaned call is a large gateway issue and not a 
>big issue for small units. I am essentially splitting the states into two. 
>One for the calls and another for Gateways/proxy as a whole. You will have 
>to keep track of all the UA registered/subscribed to the service only. I 
>am failing to understand how that could be a huge overhead. This will be 
>like any other Subscriber/notify operation. The deciding factor is the 
>"UPTIME" in the message which indicates whether there was a restart, which 
>is the reason why we have orphans, of the peer. Please educate me if I am 
>missing something.
>
>The assumption here, which I should have explained, is that calls will be 
>started only after the gateway subscriber to the feature. Upon 
>>for which it is holding state (has a dialog with), then issue a reINVITE, 
>>UPDATE, or BYE as appropriate for each dialog.
>