1. Prepaid billing 2. IF user gets disconnected due to electricity, SER must know that
From: Jan Janak jan@iptel.org To: Kapil Dhawan sersavvy@hotmail.com CC: serusers@lists.iptel.org Subject: Re: [Serusers] SER + B2BUA Date: Sun, 28 Mar 2004 20:07:23 +0200
It is not easy to implement a B2BUA on top of ser, what functionality do you need exactly ?
Jan.
On 22-03 12:03, Kapil Dhawan wrote:
Hi all i don't want to use B2BUA but need the features of it....so want to
write
some small module for it.....can anyone suggest me how to proceed with it.....
what all changes shud i look forward too and where to get the start for
it
regards
Get head-hunted by 10,000 recruiters.
http://go.msnserver.com/IN/44798.asp
Post your CV on naukri.com today.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_________________________________________________________________ Easiest Money Transfer to India. Send Money To 6000 Indian Towns. http://go.msnserver.com/IN/42198.asp Easiest Way To Send Money Home!
can anyone give more details on the same.
Do we need to change any config on ser to work with B2BUA. Can we have both ser and B2Bua running on same system. I
Kapil Dhawan sersavvy@hotmail.com wrote: 1. Prepaid billing 2. IF user gets disconnected due to electricity, SER must know that
From: Jan Janak To: Kapil Dhawan CC: serusers@lists.iptel.org Subject: Re: [Serusers] SER + B2BUA Date: Sun, 28 Mar 2004 20:07:23 +0200
It is not easy to implement a B2BUA on top of ser, what functionality do you need exactly ?
Jan.
On 22-03 12:03, Kapil Dhawan wrote:
Hi all i don't want to use B2BUA but need the features of it....so want to
write
some small module for it.....can anyone suggest me how to proceed with it.....
what all changes shud i look forward too and where to get the start for
it
regards
Get head-hunted by 10,000 recruiters.
http://go.msnserver.com/IN/44798.asp
Post your CV on naukri.com today.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_________________________________________________________________ Easiest Money Transfer to India. Send Money To 6000 Indian Towns. http://go.msnserver.com/IN/42198.asp Easiest Way To Send Money Home!
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
--On 29 March 2004 05:07 +0000 Kapil Dhawan sersavvy@hotmail.com wrote:
- Prepaid billing
- IF user gets disconnected due to electricity, SER must know that
I don't know why you need a B2BUA for either of those. On (1), you 'just' need a proxy, accounting, and some way of topping up credit (IVR and/or web site). (2) is harder. You are best-off hoping either that your media gateway will detect the lack of a media stream and close the session, or if you are proxying the media stream anyway, relying on the proxy to somehow close the session.
Alex
You can't make 1. without a B2BUA. Who else will disrupt the call in case of zero balance?
klaus
Alex Bligh wrote:
--On 29 March 2004 05:07 +0000 Kapil Dhawan sersavvy@hotmail.com wrote:
- Prepaid billing
- IF user gets disconnected due to electricity, SER must know that
I don't know why you need a B2BUA for either of those. On (1), you 'just' need a proxy, accounting, and some way of topping up credit (IVR and/or web site). (2) is harder. You are best-off hoping either that your media gateway will detect the lack of a media stream and close the session, or if you are proxying the media stream anyway, relying on the proxy to somehow close the session.
Alex
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--On 29 March 2004 10:38 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
You can't make 1. without a B2BUA. Who else will disrupt the call in case of zero balance?
Perhaps I am missing something, but why not either a) The media gateway, or b) Assuming you have a stateful proxy, the proxy server (with suitable hackery) - how would the UA/proxy upstream/downstream from the proxy *know* if the proxy really received a BYE, or just faked one up? So if you send one BYE in each direction, you get two ACK packets produced which would perhaps confuse their final recipient, except the proxy server will eat them.
Alex
Alex Bligh wrote:
--On 29 March 2004 10:38 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
You can't make 1. without a B2BUA. Who else will disrupt the call in case of zero balance?
Perhaps I am missing something, but why not either a) The media gateway, or
Are there gateways which can tear down active calls on bevave of some other component? Another problem ocours if the gateway does not belong to you (using a SIP-PSTN-termination provider).
b) Assuming you have a stateful proxy, the proxy server (with suitable hackery) - how would the UA/proxy upstream/downstream from the proxy *know* if the proxy really received a BYE, or just faked one up? So if you send one BYE in each direction, you get two ACK packets produced which would perhaps confuse their final recipient, except the proxy server will eat them.
You would need a call staful proxy (ser is only transaction stateful). The proxy would have to generate the BYE messages - so per definition - it is no more a proxy, because proxies don't generate requests on their own, they just forward requests. So this thing must be called B2BUA.
Klaus
--On 30 March 2004 10:47 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
Perhaps I am missing something, but why not either a) The media gateway, or
Are there gateways which can tear down active calls on bevave of some other component?
Cisco can tear down on (for instance) lack of rtp/rtcp.
b) Assuming you have a stateful proxy, the proxy server (with suitable hackery) - how would the UA/proxy upstream/downstream from the proxy *know* if the proxy really received a BYE, or just faked one up? So if you send one BYE in each direction, you get two ACK packets produced which would perhaps confuse their final recipient, except the proxy server will eat them.
You would need a call staful proxy (ser is only transaction stateful). The proxy would have to generate the BYE messages - so per definition - it is no more a proxy, because proxies don't generate requests on their own, they just forward requests. So this thing must be called B2BUA.
I know proxies don't *normally* do this, I just can't see why it wouldn't work if one did (if the requirement is only to produce a BYE). Whatever you end up calling it.
Alex
Alex Bligh wrote:
I know proxies don't *normally* do this, I just can't see why it wouldn't work if one did (if the requirement is only to produce a BYE). Whatever you end up calling it.
Yes, but the proxy would need to store call-id, to-tags, from-tags during the call - I don't know if this is easy to implement.
klaus
--On 31 March 2004 14:08 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
Yes, but the proxy would need to store call-id, to-tags, from-tags during the call - I don't know if this is easy to implement.
Indeed. But haven't you just described the dialog, which one presumes ser needs to store in order to do stateful proxying (t_relay etc.)? (no I haven't read the code).
Alex
yes, but as soon as the transcation is finished 8or some time later) ser will delete this transaction from memory.
klaus
Alex Bligh wrote:
--On 31 March 2004 14:08 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
Yes, but the proxy would need to store call-id, to-tags, from-tags during the call - I don't know if this is easy to implement.
Indeed. But haven't you just described the dialog, which one presumes ser needs to store in order to do stateful proxying (t_relay etc.)? (no I haven't read the code).
Alex
--On 31 March 2004 18:02 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
yes, but as soon as the transcation is finished 8or some time later) ser will delete this transaction from memory.
Indeed - ser would need to store these things for at least the duration of the call. One presumes there is already a requirement to store per-call data for rather longer than this anyway, as the original problem was to in the context of this data being used for accounting wasn't it? :-)
Alex
So, what was the problem at all? :-)
oh yes, prepaid, hm.... I don't like the idea of hang up calls by modified ser (sending BYE to both sides) - it is a dirty solution. Therefore a real B2BUA should be used, and I think this is not easy to achieve with ser - maybe easier with sems.
you can also wait for maxim's b2bua release or try asterisk.
klaus
Alex Bligh wrote:
--On 31 March 2004 18:02 +0200 Klaus Darilion klaus.mailinglists@pernau.at wrote:
yes, but as soon as the transcation is finished 8or some time later) ser will delete this transaction from memory.
Indeed - ser would need to store these things for at least the duration of the call. One presumes there is already a requirement to store per-call data for rather longer than this anyway, as the original problem was to in the context of this data being used for accounting wasn't it? :-)
Alex