Hi; The best and secure way to handle billing application is using a B2BUA SIP server. It is true that a call statefull Proxy can eventually do that, But in a distributed environment, where more than one proxy can handle the same administrative domain the INVITE and BYE can be sent to different proxies. If you use a proxy for billing you have to be 100% sure that the User Agent will honor the Record-Route header and will send future request ( like bye ) to the proxy. Using a B2BUA is the preferable way of doing real-time billing.
Regards Diego B Manjunath Warad wrote: >Hi Priya, > Proxy doesn't create fresh INVITE, it just forwards the same INVITE >by adding the route or changing the Request-Uri to User B. In the same way >it forwards the response sent by User B to User A. So, there is no need to >generate any reINVITE to A. Moreover, being a stateful proxy it can have >call awareness based on which it can charge the User A. > For e.g, Proxy can start charging A when 200 OK for INVITE is >forwarded and it may stop charging once the 200 OK for BYE is forwarded. >This is just an example how a stateful proxy with call awareness can handle >billing application. > >Regards, >Manju > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of priya pandit >Sent: Wednesday, December 07, 2005 1:47 PM >To: [EMAIL PROTECTED] >Cc: [email protected] >Subject: Re: [Sip-implementors] Real time usage > > >Hi Gururaj, > >Thanks for the clarification. >I am more concerned about how it is used in the case of a mobile service >provider supporting SIP. > >If User A wants to contact User B, he sends an INVITE directed to the SIP >Proxy located at the service station. This Proxy has to locate User B and >then connect A to B. This would need a fresh INVITE from Proxy to B and then >a reINVITE from Proxy to A. > >This proxy also has to take care of charging User A for the call he has >made. Can a normal Proxy take care of all these things? Or is every service >provider using only a B2BUA? > >Regards, >Priya. > > > >On 12/6/05, [EMAIL PROTECTED] < >[EMAIL PROTECTED]> wrote: > > >> >> >> >>Hi priya, >> >>B2BUA is not just an stateful proxy. Its much more complicated to >>write B2BUA than even a stateful proxy. A B2BUA would for example need >>to handle PRACK, probably >>SUBSCRIBE/NOTIFY and any future extensions that you want to use. A >>stateful >>proxy >>does not need to change when a new extension is introduced, since it just >>passes >>SUBSCRIBE/NOTIFY/PRACK/WHATEVER on. >> >>If you just want to route SIP messages you do not need a B2BUA. If you >>want to hide one >>side from the other (for anonymity for example), then you do require >>B2BUA. >> >>Rgds, >>Gururaj K. >> >> >> >> >> priya pandit >> <[EMAIL PROTECTED] >> ail.com> To >> Sent by: [email protected] >> sip-implementors- cc >> [EMAIL PROTECTED] >> ia.edu Subject >> [Sip-implementors] Real time >>usage >> >> 12/06/2005 11:51 >> AM >> >> >> >> >> >> >> >>Hi, >>Please correct me if I am wrong. >>B2BUA is a stateful proxy that performs third party call control. >> >>Do all the service providers, (for ex. mobile services providers >>supporting >>SIP) use only a B2BUA and never a SIP stateless proxy since B2BUA can >>maintain states and connect two users, provides other voice and data >>services and helps in billing? >> >>Regards, >>Priya. >>_______________________________________________ >>Sip-implementors mailing list [email protected] >>https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >> >> >>*********************** FSS-Unclassified *********************** >>"DISCLAIMER: This message is proprietary to Hughes Software Systems >>Limited >>(HSS) and is intended solely for the use of the individual to whom it is >>addressed. It may contain privileged or confidential information and >>should not be circulated or used for any purpose other than for what it is >>intended. If you have received this message in error, please notify the >>originator immediately. If you are not the intended recipient, you are >>notified that you are strictly prohibited from using, copying, altering, >>or >>disclosing the contents of this message. HSS accepts no responsibility for >>loss or damage arising from the use of the information transmitted by this >>email including damage from virus." >> >> >> >> >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >_______________________________________________ >Sip-implementors mailing list >[email protected] >https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
