On Jan 7, 2009, at 9:47 AM, Jiri Kuthan wrote:
Adrian Georgescu wrote:
I beg to differ, but this is just my humble opinion based on my
experience with my particular customers.
The most economic and future-proof way to perform accounting for
SIP sessions is the SIP Proxy server alone.
This may be probably ok, as long as you don't intend to use such
accounting
data for billing. (which may be still useful)
I really mean accounting for billing purpose.
The trouble is that proxy-produced accounting data is remarkable
incomplete and
inaccurate. It does not include QoS info, PSTN info, and they are
sensitive to
the attacks mentioned before that make a BYE work for a GW but not
for a proxy
and vice versa, or other ways how BYE can be broken due to an error
or fraud.
Again these are issue that need to be addressed and do not imply that
SIP Proxy accounting is not possible or undesirable.
My personal experience is that gateways come and go in a provider
configuration and they are in many cases under the control of a
third-party that provides the PSTN termination service. When you do
LCR across many different gateways, which are not even yours the
only aggregation point for traffic is the SIP proxy that
authenticates and authorizes the requests. Over time, the gateways
change hands, get upgraded or removed much more often then the
proxy itself, which maintains its central role over time.
There is certainly some invariable in a system but to my best
knowledge
that's the DB backend (for example RADIUS) which gets almost never
touched,
not a proxy server. The DB is the piece that is invariable,
untouchable,
central in every respect, and therefore used for aggregation of
usage data,
as directly as possible. I see little value on putting a SIP proxy
on the
way from the service box knowing ALL call data and the final
destination
of the usage data (some database).
When I referred to the accounting of the SIP Proxy server my intention
was to denominate "The accounting server (like Radius) associated with
the SIP Proxy and its DB backend" as in your example. So we talk about
the same thing.
(I agree proxy is the best place for authorization and
authentication but that's
a different story than accounting.)
Secondly, once you
do more the voice like video and other services that require
billing and are not PSTN related, the SIP Proxy is the only network
element that has access to the signalling and is able to generate
accounting tickets.
That seems appealing indeed, it is just that I have encountered very
few (still some
though) who would be seriously billing for on-net calls on a per-
minute basis.
(they haven't found a way to do sell credibly a single usrloc lookup
on a per-minute basis or didn't consider the on-net share of traffic
significant or
thought the CDR producing expense was just not worth it) It makes
sense as you say
to produce CDRs in a proxy if termination is provided by a third
party, but to my
best knowledge these are based on their inaccuracy used for
reconciliation rather
than as source of authoritative data.
There are SIP service numbers that are not available on PSTN and
charged per minute like PSTN destinations. Then there are peering
agreements that allow calls to be routed based on results of ENUM
lookups and still charged per minute. No gateway involved just an ENUM
lookup. Only the SIP Proxy knows this information.
Solving the accounting related problems at the SIP Proxy level is a
worthwhile investment
Yes, but only if you don't care about accuracy and completeness of
the usage data,
i.e., you don't do billing. Otherwise the customer-care cost is
unpayable in addition
to the expense of doing it at all. The per-minute margins are so
poor and accurate
CDR processing is such an expense,
I beg to differ. The accounting can be as accurate as any other source
like the PSTN gateway if you consider that a relevant comparison
factor. The fact that a particular implementation does not address the
flaws mentioned here does not rule out SIP Proxy accounting is not good.
that it alone explains the increasing flat-rate
offerings. We have been doing it only in the reconciliation case you
mentioned,
merely as non-authoritative data.
If you however do have a scenario, in which accuracy and
completeness matters for
billing sake, investment in proxy-based CDR production seems to me
only likely to
produce liability.
So is no debate here.
-jiri
while other options are just temporary fixes that
work in a particular case for a limited amount of time and that is
a waste of money.
Adrian
On Jan 7, 2009, at 2:25 AM, Jiri Kuthan wrote:
authentication does not provide actually value here. dialog would
not
either, since
the same trick can be achieved for example by low max-forwards.
IMO the
proper
choice is accounting from the gateway, which provides the actual
service.
A proxy can only provide an approximation which is inherentely to
some
extent
more error-prone than the box doing the actual job.
-jiri
Bogdan-Andrei Iancu wrote:
Hi Iñaki,
Have you consider requesting auth for the BYE ? from SIP point of
view
is perfectly valid....
Regards,
Bogdan
Iñaki Baz Castillo wrote:
Hi, I'm thinking in the following flow in which the caller/
attacker
would get an unlimited call (but a limited CDR duration):
--------------------------------------------------------------------------
attacker OpenSIPS (Acc)
gateway
INVITE (CSeq 12) ------>
<-------- 407 Proxy Auth
INVITE (CSeq 13) ------>
INVITE (CSeq 13)
------>
<-------------------
200 Ok
<------------------- 200 Ok
<< Acc START >>
ACK (CSeq 13) ----------->
ACK (CSeq 13)
----------->
<******************* RTP ************************>
# Fraudulent BYE !!!
BYE (CSeq 10) ----------->
<< Acc STOP >>
BYE (CSeq 10)
----------->
<-- 500 Req Out of
Order
<-- 500 Req Out of Order
--------------------------------------------------------------------------
The call hasn't finished, but OpenSIPS has ended the accounting
for
this call since it received a BYE. And this BYE will generate a
correct ACC Stop action (since it matches From_tag, To_tag and
Call-ID).
I think this is *VERY* dangerous and I hope I'm wrong.
Would help the dialog module here? does the dialog module check
the
CSeq of the BYE in some way and could it prevent OpenSIPS from
generating the ACC STOP action? (I don't think so).
Any idea?
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
