Thanks to Diego B, Rajesh V R and Wayne Davies for their answers.

I need to specify some questions. My role is to add a feature in a SIP network 
to be able to do billing on a session.

Of course it must be generic and reusable. I understant why a simple SIP proxy 
won't be a good idea. I had a look to 3CPP server, like the sun one using jain, 
and I see what is missing in my simple proxy architecture. 

If I understand well, you suggest this kind of architecture :

         _______________                         _______________
        |               |                       |               |
        |   SIP Proxy   |       <-------->  |     B2BUA     |   
        |_______________|                       |_______________|
             ^       ^
             |        \
             v         \
         _______________        \  _______________
        |               |        v|               |
        |   UA A        |         |   UA B        |
        |_______________|         |_______________|


My "new" idea would be a SIP proxy with a B2BUA
UA A send an INVITE request, Proxy check for authentication, then INVITE is 
forward to B2BUA, which send back an invite for UA B to SIP proxy if 
authorization (and accouting) is ok.

When no more money is left, B2BUA sends 1 or more BYE to each UA connected 
through the proxy.

That is what I understand when I look at some B2BUA architectures (Radvision 
ENSEMBLE or PortaSIP, I found some powerpoint files on google).

I can add a RTP Proxy too.

But my purpose is only to bill a sip session in a realtime prepaid context. 
Prepaid means prepaid by money, which can give x minutes of call, or y kb of 
download.

My role is to study if SIP could be a good way to have concurrent use on a same 
balance with voice and web at the same time ... And how realize it. I 
understand when you explain me that proxy is not a safe way to do it, but how 
is it possible to "check a few media packets to calculate amount of data ( 
media ) streamed per second, type of codec used, video or voice, etc ( this 
will not work with silence supression )." without having a RTP proxy ? 

I just need for audio or video a time duration, so a begin time, the final end 
time, and renew the permission each x seconds or minuts to reserv money on the 
balance
For data (web), I need to know what amount of data had passed through the 
stream from begin time of the session till now.

Thank you again for your answers. You're helpful ;)

Guillaume


-----Message d'origine-----
De : Diego B [mailto:[EMAIL PROTECTED] 
Envoy� : vendredi 15 avril 2005 16:55
� : Des Pommare Guillaume
Cc : [email protected]
Objet : Re: [Sip-implementors] SIP Billing proxy with billing on amount of data 
and not on time

Hi;

First of all I thing a SIP Proxy server is not the right place to do SIP 
billing, the sip proxy is defined as a transactinal engine, so there is no way 
it can correlate INVITE and BYE transactions ( I know, there are lot of ways to 
do that, but I'm refering to the standard.).
.
One end-point may send ACK or BYE directlly to the other end-point skiping the 
proxy, so you will end up with lot of calls.
You may be using Record-Route, but htis not ensure you the end points will 
support this.
the best solution is to use a 3PCC server implmeneting a B2BUA.
There you can control the 2 legs of the call. You can also check a few media 
packets to calculate amount of data ( media ) streamed per second, type of 
codec used, video or voice, etc ( this will not work with silence supression ).

Regards
Diego B..

Des Pommare Guillaume wrote:

>Hi !
> 
>I'm in charge of creating a SIP billing proxy. For the moment I have no 
>real problem to do it with billing on time duration. But what about 
>billing on amount of data, for example 5$/Mb ?
> 
>I set a timer on a 200OK from callee, and stop it on a BYE (end of 
>balance or BYE from the callee or caller). This give me a time duration.
>
> 
>If I want to make billing on amount of data, should I set up a RTP 
>proxy server? this is "expensive" to do with huge traffic, and operator 
>should be in charge of that kind of thing, not our billing proxy.
> 
>Is there any way (from example with SDP) to be inform of amount of data 
>transmitted during a session ?
> 
>I am not really famialiar with SIP, I just study it since 2 weeks, and 
>I found this problem in the SIP FAQ of  Jonathan Rosenberg, this could 
>be possible if the operator's gateway record "call" informations. If 
>there is no gateway, what can be done ? (in a SIP only environment)
>
>
>"How do I charge/bill for Internet telephony using SIP?
>
>    This depends on whether you plan to charge for SIP services like 
>directory look-ups, call processing or mobility, for gateway services 
>to the PSTN, or for carrying media data:
>
>    SIP services
>        The Authorization header can be used to indicate a customer 
>identity that associates a SIP request with a billable entity.
>
>        Examples of possibly chargeable SIP services include:
>
>            * Directory services such as SIP proxy/redirect lookups;
>            * Customer profile management;
>
>        SIP server operations can be charged based on server logs or, 
>for real-time billing, via AAA.
>    Media services
>        Media services include retrieving and storing voice mail, as 
>well as transcoding of media streams. They are not initiated by SIP, 
>but, for example, via RTSP.
>    
>       Gateway services
>        Similar to SIP services. Care has to be taken to stop billing 
>when (say) RTP voice data is no longer flowing through the gateway. The 
>gateway will generate call detail records (CDRs) either directly or 
>through RADIUS."
>
>Thanks
>
>Guillaume
>
>PS : sorry if my questions seems quite simple, for me there are 
>difficult to assimilate ;)
>
>_______________________________________________
>Sip-implementors mailing list
>[email protected]
>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>  
>



_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to