Sushil,
This method is ok to use and is defined in the draft-ietf-session-timer-xx, the latest I have is v13, you should download and read the latest version of this doc. It describes the function of what you are looking at using a Re-INVITE or UPDATE method. But there are some factors around using a feature such as this especially for billing, this is a message thread that seems to get repeated alot. I have seen recently in a response to a similar query someone posted the link to an existing message thread that you should read and follow, but I did not save that email - some out there may be able to send it to you.
The ability to terminate a call and therefore close a billing record has been seen as a good advantage of using such a feature, but this was not the purpose or original motivation for this feature. Some things to think about;
- The more accurate the billing the more frequently you will want to refresh the session to determine if it is still valid, which had a corresponding increase in the amount of messages you are generating - per active call*.
- Along with session refresh is other timed events like registration, you set session refresh less than the registration interval and a registration will time out on your B2BUA / Proxy - the refresh will unable to be generated, failing the refresh and the subsequently tearing down one side of the call (?).
- The IP path between the end points will be different to between the individual end points and the proxy. A temporary network failure / congestion etc may mean that two end UA's are talking normally but the periodic session refresh fails to reach one of the end UA's. The session refresh will fail and subsequently the B2BUA / Proxy will tear down the call.
As mentioned by Alex some media Gateways (again we will use Cisco) have not only RTP but RTCP detection capabilities, this allows for session accuracy in that it will not act on absence of media - user on mute, VAD etc. A loss of RTCP can be detected immediately, free resources and BYE the call and requires no addition messaging during the duration of the call. There are alot of benefits in having the end UA's perform this function.
Regards,
Wayne Davies
email: [EMAIL PROTECTED]
"Sushil Kumar Verma" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]19/03/2004 05:16 AM
To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] How to stop CDR?
Hi,
Thanks for the resoponses.
What if we dont have any gateway(or RTP Proxy) in between? Suppose a proxy who is also responsible for billing is the only entity between SIP UAs...
What is wrong if proxy/B2BUA sends OPTIONS to each party at regular interval and if 200 OK is not received , disconnect the call and stop billing? (Any way all SIP entity are suppose to support OPTIONS).
thanks and regards,
Sushil Kumar,
Axes Technologies (I) Pvt. ltd.
-------Original Message-------
From: Alex Bligh
Date: 03/18/04 19:40:57
To: Christian Stredicke; 'Sushil Kumar Verma'
Cc: [EMAIL PROTECTED]; Alex Bligh
Subject: RE: [Sip-implementors] How to stop CDR?
--On 18 March 2004 09:24 +0100 Christian Stredicke <[EMAIL PROTECTED]>
wrote:
> One way with the currently existing standards is to run the call trough a
> trusted UA of the billing entity. That entity can measure on the RTP (or
> RTCP) level if the connection is still alive. Typically, this UA will be
> a PSTN gateway or a B2BUA (back-to-back user agent).
Some media gateways (e.g. Cisco) have RTP media inactivity timers and
will tear down a SIP session if RTP goes dead (which is generally a
good idea). This (IMHO) all but solves the PSTN problem.
The SIP<->SIP problem is harder. But again, if you are running an
RTP proxy, you could detect inactivity there and tear down the SIP
session. This would also not be a bad idea for tearing down failed
or one/way connections through NATs/firewalls now I come to think
of it. Clearly that's only going to work for an RTP payload.
Beyond that, it would require a change to, or some innovative (ab)use
of the SIP standard to effect some form of keepalive. But note checking
SIP server still has IP connectivity to the UA does not check that a
functional call is still in progress. It could be (for instance) that
the remote end has disconnected, the RTP's dropped etc.
Alex
____________________________________________________
IncrediMail - Email has finally evolved - Click Here _______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.
Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
