Paul Kyzivat wrote:
>
> Iñaki Baz Castillo wrote:
>> El Jueves, 18 de Diciembre de 2008, Paul Kyzivat escribió:
>>> You are tying this to the GW because the GW has a cost to you?
>>> If so, then why isn't it the GW that is generating the accounting?
>>>
>>> Or are you saying that you are routing t
Paul Kyzivat wrote:
> The problem here is that you have a device that is trying to charge, but
> controls nothing to enforce its charging. If it wants to charge, then it
> ought to have something (e.g. the media stream) that it can "turn off"
> when the call terminates. Then there won't be fraud
On Thu, 2008-12-18 at 18:57 +0100, Alex Hermann wrote:
> On Thursday 18 December 2008 18:38:53 Paul Kyzivat wrote:
> > You are tying this to the GW because the GW has a cost to you?
> > If so, then why isn't it the GW that is generating the accounting?
> >
> > Or are you saying that you are routing
Iñaki Baz Castillo wrote:
> El Jueves, 18 de Diciembre de 2008, Paul Kyzivat escribió:
>> You are tying this to the GW because the GW has a cost to you?
>> If so, then why isn't it the GW that is generating the accounting?
>>
>> Or are you saying that you are routing the call to a GW, not control
El Jueves, 18 de Diciembre de 2008, Paul Kyzivat escribió:
> You are tying this to the GW because the GW has a cost to you?
> If so, then why isn't it the GW that is generating the accounting?
>
> Or are you saying that you are routing the call to a GW, not controlled
> by you, that will bill you?
On Thursday 18 December 2008 18:38:53 Paul Kyzivat wrote:
> You are tying this to the GW because the GW has a cost to you?
> If so, then why isn't it the GW that is generating the accounting?
>
> Or are you saying that you are routing the call to a GW, not controlled
> by you, that will bill you? A
You are tying this to the GW because the GW has a cost to you?
If so, then why isn't it the GW that is generating the accounting?
Or are you saying that you are routing the call to a GW, not controlled
by you, that will bill you? And you want to generate your own accounting
so you can bill back
2008/12/18 Alex Hermann :
> On Thursday 18 December 2008 15:10:21 Iñaki Baz Castillo wrote:
>> What about if the gateway sends a valid BYE, the proxy forwards it to
>> the user and the user doesn't reply 200 OK?
>> If the proxy should rely on the 200 OK for BYE then the this call
>> wouldn't be acc
On Thursday 18 December 2008 15:10:21 Iñaki Baz Castillo wrote:
> What about if the gateway sends a valid BYE, the proxy forwards it to
> the user and the user doesn't reply 200 OK?
> If the proxy should rely on the 200 OK for BYE then the this call
> wouldn't be accounted.
The accounting should e
2008/12/18 Paul Kyzivat :
>> IMHO, the only solution here (without handling RTP) is a B2BUA that
>> does accounting and also SessionTimers in clients leg and carriers
>> leg.
>
> You can get the same effect with a call-stateful proxy that uses Session
> Timer.
Sorry??? a proxy cannot generate in-
Iñaki Baz Castillo wrote:
> 2008/12/18 Paul Kyzivat :
>> The problem here is that you have a device that is trying to charge, but
>> controls nothing to enforce its charging. If it wants to charge, then it
>> ought to have something (e.g. the media stream) that it can "turn off" when
>> the call
2008/12/18 Alex Hermann :
> On Thursday 18 December 2008, you wrote:
>> On Thu, Dec 18, 2008 at 12:18 PM, Alex Hermann wrote:
>> > Second, you should stop accounting on receiving the response on the BYE
>> > (200 OK) instead of on receipt of the request.
>>
>> Note that you might have no response
2008/12/18 Paul Kyzivat :
> The problem here is that you have a device that is trying to charge, but
> controls nothing to enforce its charging. If it wants to charge, then it
> ought to have something (e.g. the media stream) that it can "turn off" when
> the call terminates. Then there won't be fr
On Thursday 18 December 2008, you wrote:
> On Thu, Dec 18, 2008 at 12:18 PM, Alex Hermann wrote:
> > Second, you should stop accounting on receiving the response on the BYE
> > (200 OK) instead of on receipt of the request.
>
> Note that you might have no response at all and hence wait for the
> c
The problem here is that you have a device that is trying to charge, but
controls nothing to enforce its charging. If it wants to charge, then it
ought to have something (e.g. the media stream) that it can "turn off"
when the call terminates. Then there won't be fraud.
If the proxy doesn't cont
2008/12/18 Victor Pascual Ávila :
>> How could a non dialog awareness proxy solve it?
>
> In case you want to prevent "external_attackers", the proxy may ask
> for authentication once it receives the BYE request (as you show for
> the initial INVITE message):
Don't try it with Asterisk as client a
On Thu, Dec 18, 2008 at 12:18 PM, Alex Hermann wrote:
> Second, you should stop accounting on receiving the response on the BYE (200
> OK) instead of on receipt of the request.
Note that you might have no response at all and hence wait for the
client transaction timeout.
--
Victor Pascual Ávila
On Thursday 18 December 2008, Iñaki Baz Castillo wrote:
> Hi, I really wonder how vulnerable can be a proxy for accounting
> purposes (even if I already know it's commonly implemented).
> Theorically a proxy doesn't need to be dialog aware, it must be
> transaction aware, so when an INVITE/CANCEL/B
On Thu, Dec 18, 2008 at 11:44 AM, Iñaki Baz Castillo wrote:
> Hi, I really wonder how vulnerable can be a proxy for accounting
> purposes (even if I already know it's commonly implemented).
> Theorically a proxy doesn't need to be dialog aware, it must be
> transaction aware, so when an INVITE/CAN
I would answer do not account on a non-dialog aware proxy.
2008/12/18 Iñaki Baz Castillo
> Hi, I really wonder how vulnerable can be a proxy for accounting
> purposes (even if I already know it's commonly implemented).
> Theorically a proxy doesn't need to be dialog aware, it must be
> trans
Hi, I really wonder how vulnerable can be a proxy for accounting
purposes (even if I already know it's commonly implemented).
Theorically a proxy doesn't need to be dialog aware, it must be
transaction aware, so when an INVITE/CANCEL/BYE arrives it sends the
accounting info (for example, using Radi
21 matches
Mail list logo
