Hi all.
Could you guys please tell me how federation is done in multiple domains
SIP ? What are open/enhanced, Direct federations ? How is it
different from "aggregation" in SIP request/response routing ?
Thank you in advance.!
Thanks and regards
Nabam Serbang
_
Billing is made based on operator or service providers if you like to
read standards you can see some 3gpp documents Ro(online charging) and
Rf (offline) Rx(policy and charging control) Diameter Interfaces has
been used.
Regards
Oviaprasad D
ESN: 6-877-7352
-Original Message-
From: sip-im
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
The problem is that without knowing if the uri is a resource list or not,
the subscribe request should not considered valid (the 202 response implies
it is valid), since the Accept (must support multipart and rlmi) and
Supported (must have eventlist option) headers may be invalid. In a server
where
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 Wed, 2008-12-17 at 15:35 +, Eduardo Martins wrote:
> my understanding of the RLS specs is that we can't return a 202
> with pending subscription back to the subscriber
I don't understand -- the 202 response code is designed for the
situation where the SUBSCRIBE has been processed but the no
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
Hi all,
Can you please explain me how billing is done in SIP call in brief? Any
rfcs' ?
Thanks and regards
Nabam Serbang
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-
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-
Yes, or course it can be there.
Don't assume that because you sent it once you don't need to send it
again. There is nothing that says any of the Allow-* or Accept-* headers
are scoped to a dialog. How long the commitment is to honor one of these
headers is unspecified. So you had best put them
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
Hi,
It's mentioned in RFC 3265, Section 3.3.7 that
Any node implementing one or more event packages SHOULD include an
appropriate "Allow-Events" header indicating all supported events in
all methods which initiate dialogs and their responses (such as
INVITE) and OPTIONS responses.
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
28 matches
Mail list logo
