At 04:14 PM 12/30/2004, Matt Schulte wrote:
I don't like the idea of having 2 or 3 programs in my path.
Neither do I :-) Asterisk is a stateful *ahem* softswitch/proxy, that always generates a BYE. It communicates directly with whatever it connects to, unless you redirect of course. I wouldn't use Asterisk for this purpose of course for many reasons either, I was just making a point :-)
Which was right.
A technique I favor is relying on trustable media gateway. Trustable means it is in your hands and you can rely on it to detect dead calls (either by lack of RTCP or using session-timer) and hang up properly.
However, in production environments a CDR mediation devices ideally collects CDRs from the gateway -- the reasons is that the gateway knows all information best. All in all, it is the place which provides the service in question. It knows even media status and PSTN signaling status.
Well -- people may wonder why I am mentioning just the case with PSTN gateway. What happens if there is no such and it is an IP-to-IP call? My suggestion
is to forget charging and producing CDRs.
-jiri
Jiri Kuthan writes:
Well -- people may wonder why I am mentioning just the case with PSTN gateway. What happens if there is no such and it is an IP-to-IP call? My suggestion is to forget charging and producing CDRs.
i fully agree. this topic has been discussed on the list a few times already and newcomers can check the archives for details.
-- juha
Jiri Kuthan wrote:
At 04:14 PM 12/30/2004, Matt Schulte wrote:
I don't like the idea of having 2 or 3 programs in my path.
Neither do I :-) Asterisk is a stateful *ahem* softswitch/proxy, that always generates a BYE. It communicates directly with whatever it connects to, unless you redirect of course. I wouldn't use Asterisk for this purpose of course for many reasons either, I was just making a point :-)
Which was right.
A technique I favor is relying on trustable media gateway. Trustable means it is in your hands and you can rely on it to detect dead calls (either by lack of RTCP or using session-timer) and hang up properly.
However, in production environments a CDR mediation devices ideally collects CDRs from the gateway -- the reasons is that the gateway knows all information best. All in all, it is the place which provides the service in question. It knows even media status and PSTN signaling status.
Well -- people may wonder why I am mentioning just the case with PSTN gateway. What happens if there is no such and it is an IP-to-IP call? My suggestion
is to forget charging and producing CDRs.
-jiri
My problem is that we don't control the SIP to PSTN gateway, so all our calls are SIP:SIP without the possibility to check the gateway, if one side hang up it is likely that the other side will create a BYE, however if both sides are disconnected, we have a problem.
At 09:03 AM 12/31/2004, Erik Versaevel wrote:
My problem is that we don't control the SIP to PSTN gateway,
That appears to me to be a problem of trading costs of different solutions.
What we have been deploying is a system in which you trust a third-party gateway to generate BYEs and send CDRs to you. The risk of having inaccurate CDRs depends on reliability and trustworthness of the third party. It seems to be an acceptable risk -- all in all it is CDRs what they get their money for.
You may wish to introduce an additional source of CDR in your system for sake of verification -- some kind of call stateful element which observes call status. However, the costs of such a solution do not appear to me to justify the benefits -- proxying media, keeping call state, interop issues with calls on hold or silence detection,and possibly more.
so all our calls are SIP:SIP without the possibility to check the gateway, if one side hang up it is likely that the other side will create a BYE, however if both sides are disconnected, we have a problem.
I am not sure if there is a value in a CDR for a call to a gatrway which exited abruptly.
-jiri
-
Erik Versaevel -
Jiri Kuthan -
Juha Heinanen