Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
Would it be possible to fake a REINVITE then check the response to determine if a call is still in session? Just brainstorming...
- Daryl
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to reINVITE, works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco gateways, but I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
Would it be possible to fake a REINVITE then check the response to determine if a call is still in session? Just brainstorming...
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Hi Greg,
that's the fortunate case of having already a B2BUA on the path :). But only for this particular case, I find the usage of a B2BUA a little bit to "heavy"....
Session Timer is actually doing a great job ;)
regards, bogdan
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to reINVITE, works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco gateways, but I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
Would it be possible to fake a REINVITE then check the response to determine if a call is still in session? Just brainstorming...
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
problem with session timers, is if you have several different routes and you dont control all the end gateways....then its a pain, so I would think you would need a plan B, just in case to ensure you double checked, but agree with bogdan, b2bua i great but I think the overhead is not needed.
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Greg,
that's the fortunate case of having already a B2BUA on the path :). But only for this particular case, I find the usage of a B2BUA a little bit to "heavy"....
Session Timer is actually doing a great job ;)
regards, bogdan
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to reINVITE, works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco gateways, but I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
Would it be possible to fake a REINVITE then check the response to determine if a call is still in session? Just brainstorming...
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
On 10/27/05, Iqbal iqbal@gigo.co.uk wrote:
problem with session timers, is if you have several different routes and you dont control all the end gateways....then its a pain, so I would think you would need a plan B, just in case to ensure you double checked, but agree with bogdan, b2bua i great but I think the overhead is not needed.
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Greg,
that's the fortunate case of having already a B2BUA on the path :). But only for this particular case, I find the usage of a B2BUA a little bit to "heavy"....
Session Timer is actually doing a great job ;)
regards, bogdan
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to reINVITE, works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco gateways, but I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
Would it be possible to fake a REINVITE then check the response to determine if a call is still in session? Just brainstorming...
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daryl,
normally, a PSTN provider who offer quality service must offer a way to detect hanged calls. There is also a detection mechanism based on media (on GW) - at least CISCO GW have.
regards, bogdan
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
On 10/27/05, Iqbal iqbal@gigo.co.uk wrote:
problem with session timers, is if you have several different routes and you dont control all the end gateways....then its a pain, so I would think you would need a plan B, just in case to ensure you double checked, but agree with bogdan, b2bua i great but I think the overhead is not needed.
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Greg,
that's the fortunate case of having already a B2BUA on the path :). But only for this particular case, I find the usage of a B2BUA a little bit to "heavy"....
Session Timer is actually doing a great job ;)
regards, bogdan
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to reINVITE, works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco gateways, but I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
>Would it be possible to fake a REINVITE then check the response to >determine if a call is still in session? Just brainstorming... > >- Daryl > >
Hi,
I'd also like to add my 2 cents to this topic, which might be slightly off-topic on this mailing list. Imho the problem discussed here is a major defficiency of the SIP protocol, which forces most vendors to implement proprietary extensions in their equipment. Call supervision is a feature that might not be important for best-effort services, but is of utmost importance when deploying SIP within a commercial environment.
Have a look at, e.g. H.323. They do have several redundant mechanisms to detect stale calls (e.g. at H.225 RAS level (IRQ/IRR/IACK/INAK), and at call signaling level (Status request/Status)). These messages offer detailed information on all ongoing calls within a terminal/gateway - either on sending an explicit request or by asking the endpoint to provide this information on a periodical base. Beside this, RRQ/RCF also provides re-registration features similar to REGISTER timers in SIP.
Again imho the clean solution for SIP was to have an equivalent of these features defined in the 3261 core. It's too late for this now. What still can (and should) be done is an RFC that defines an extension to SIP which implements call supervision.
Concluding: It's obvious that _real_ call supervision that is capable to detect malicious, non-standard compliant terminals (which, e.g. signal voice but send video over the voice channel) requires some border gateways featuring RTP content sniffing. But this is imho no excuse for SIP not providing standardized means capable to supervise calls on standard-compliant SIP devices.
regards --Joachim
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Bogdan-Andrei Iancu Sent: Donnerstag, 27. Oktober 2005 21:02 To: Daryl Sanders Cc: users@openser.org Subject: Re: [Serusers] Re: [Users] Detecting runaway calls
Daryl,
normally, a PSTN provider who offer quality service must offer a way to detect hanged calls. There is also a detection mechanism based on media (on GW) - at least CISCO GW have.
regards, bogdan
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call
after a certain
amount of time if there was no media detected.
On 10/27/05, Iqbal iqbal@gigo.co.uk wrote:
problem with session timers, is if you have several
different routes
and you dont control all the end gateways....then its a pain, so I would think you would need a plan B, just in case to ensure
you double
checked, but agree with bogdan, b2bua i great but I think
the overhead
is not needed.
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Greg,
that's the fortunate case of having already a B2BUA on the path :). But only for this particular case, I find the usage of a B2BUA a little bit to "heavy"....
Session Timer is actually doing a great job ;)
regards, bogdan
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to
reINVITE,
works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco
gateways, but
I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work,
or find a
PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
>by sending re-INVITEs from the middle of the path you will >increase the cseq number differently on each side...so you will >need to synchronize the cseq value when some in-the-dialog >requests are passing through your proxy....and that's quite >complicated.... > >regards, >bogdan > >Daryl Sanders wrote: > > > > > >>Would it be possible to fake a REINVITE then check the
response
>>to determine if a call is still in session? Just
brainstorming...
>> >>- Daryl >> >>
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi all!
It depends on what you expect from SIP. If you want to use it as POTS replacement, or if you want to have full control over every terminal, than I suggest using proprietary protocols.
If you are dreaming the Internet dream, then the service should be end-2-end without a service provider inspecting all signaling, payload and media.
And if there are broken clients, the clients should be fixed. Of course you can save $$ by giving cheap (broken) phones to your costumers and fix it by spending $$ for a SBC. Depending on the numbers of clients you have, it may be cheaper using cheap phones and buy the SBC.
One big problem with SBC are the service contract - you have to buy them for each year to get updates. If you detect a bug and ask for the bugfix, they ask you for $$.
Of course if your business depends on selling minutes to the PSTN and being cheaper than traditionel POTS, you have to be sure that the billing is accurate.
And do not forget - there is a great B2BUA for free - it's called "Asterisk". And it will detect dead calls as well.
regards klaus
Joachim Fabini wrote:
Hi,
I'd also like to add my 2 cents to this topic, which might be slightly off-topic on this mailing list. Imho the problem discussed here is a major defficiency of the SIP protocol, which forces most vendors to implement proprietary extensions in their equipment. Call supervision is a feature that might not be important for best-effort services, but is of utmost importance when deploying SIP within a commercial environment.
Have a look at, e.g. H.323. They do have several redundant mechanisms to detect stale calls (e.g. at H.225 RAS level (IRQ/IRR/IACK/INAK), and at call signaling level (Status request/Status)). These messages offer detailed information on all ongoing calls within a terminal/gateway - either on sending an explicit request or by asking the endpoint to provide this information on a periodical base. Beside this, RRQ/RCF also provides re-registration features similar to REGISTER timers in SIP.
Again imho the clean solution for SIP was to have an equivalent of these features defined in the 3261 core. It's too late for this now. What still can (and should) be done is an RFC that defines an extension to SIP which implements call supervision.
Concluding: It's obvious that _real_ call supervision that is capable to detect malicious, non-standard compliant terminals (which, e.g. signal voice but send video over the voice channel) requires some border gateways featuring RTP content sniffing. But this is imho no excuse for SIP not providing standardized means capable to supervise calls on standard-compliant SIP devices.
regards --Joachim
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Bogdan-Andrei Iancu Sent: Donnerstag, 27. Oktober 2005 21:02 To: Daryl Sanders Cc: users@openser.org Subject: Re: [Serusers] Re: [Users] Detecting runaway calls
Daryl,
normally, a PSTN provider who offer quality service must offer a way to detect hanged calls. There is also a detection mechanism based on media (on GW) - at least CISCO GW have.
regards, bogdan
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call
after a certain
amount of time if there was no media detected.
On 10/27/05, Iqbal iqbal@gigo.co.uk wrote:
problem with session timers, is if you have several
different routes
and you dont control all the end gateways....then its a pain, so I would think you would need a plan B, just in case to ensure
you double
checked, but agree with bogdan, b2bua i great but I think
the overhead
is not needed.
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Greg,
that's the fortunate case of having already a B2BUA on the path :). But only for this particular case, I find the usage of a B2BUA a little bit to "heavy"....
Session Timer is actually doing a great job ;)
regards, bogdan
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to
reINVITE,
works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco
gateways, but
I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
>Thanks for the info guys! It sounds like I need to do a little >reading up on cseq to determine if this will even work,
or find a
>PSTN gateway provider that supports Session-Timers. > >- Daryl > >On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote: > > > > > >>by sending re-INVITEs from the middle of the path you will >>increase the cseq number differently on each side...so you will >>need to synchronize the cseq value when some in-the-dialog >>requests are passing through your proxy....and that's quite >>complicated.... >> >>regards, >>bogdan >> >>Daryl Sanders wrote: >> >> >> >> >> >> >>>Would it be possible to fake a REINVITE then check the
response
>>>to determine if a call is still in session? Just
brainstorming...
>>>- Daryl >>> >>>
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
Yes they should - but there a thousands of GW providers which have no glue about their equipment :-(
klaus
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
1) homogenize the packets you see 2) obscure your network/customers to gateways obscure gateways to your customers 3) reduce packet size 4) provide a handy spot to kill a call in progress 5) and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
On 10/27/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
Yes they should - but there a thousands of GW providers which have no glue about their equipment :-(
klaus
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Hi Greg,
keeping the call control on your hands is an vital need...With the tomorrow release I prepared the first steps for a light dialog support based on Routing mechanism - complete FROM changing and restoring for the whole dialog was the prove of concept :). By being able to control the call from somewhere in the middle, I target especially issue no 2 and why not 4 and 5.
....and all this by avoiding the B2BUA.......
regards, bogdan
Greg Fausak wrote:
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
- homogenize the packets you see
- obscure your network/customers to gateways obscure gateways to your customers
- reduce packet size
- provide a handy spot to kill a call in progress
- and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
On 10/27/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
Yes they should - but there a thousands of GW providers which have no glue about their equipment :-(
klaus
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
That sounds very interesting. Is this a module you are working on? I agree, it would be great to have a little more control over calls without B2BUA.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Greg,
keeping the call control on your hands is an vital need...With the tomorrow release I prepared the first steps for a light dialog support based on Routing mechanism - complete FROM changing and restoring for the whole dialog was the prove of concept :). By being able to control the call from somewhere in the middle, I target especially issue no 2 and why not 4 and 5.
....and all this by avoiding the B2BUA.......
regards, bogdan
Greg Fausak wrote:
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
- homogenize the packets you see
- obscure your network/customers to gateways obscure gateways to your customers
- reduce packet size
- provide a handy spot to kill a call in progress
- and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
On 10/27/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
Yes they should - but there a thousands of GW providers which have no glue about their equipment :-(
klaus
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
It's on the way.....I just finished adding the support for it in different other modules...I cannot say yet when it will be available :(....
regards, bogdan
Daryl Sanders wrote:
That sounds very interesting. Is this a module you are working on? I agree, it would be great to have a little more control over calls without B2BUA.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Greg,
keeping the call control on your hands is an vital need...With the tomorrow release I prepared the first steps for a light dialog support based on Routing mechanism - complete FROM changing and restoring for the whole dialog was the prove of concept :). By being able to control the call from somewhere in the middle, I target especially issue no 2 and why not 4 and 5.
....and all this by avoiding the B2BUA.......
regards, bogdan
Greg Fausak wrote:
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
- homogenize the packets you see
- obscure your network/customers to gateways obscure gateways to your customers
- reduce packet size
- provide a handy spot to kill a call in progress
- and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
On 10/27/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
Yes they should - but there a thousands of GW providers which have no glue about their equipment :-(
klaus
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
great news, that way asterisk can be left to deal with all the pbx and other fancy features, and billing stays in SER...where I always think it should be.
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Greg,
keeping the call control on your hands is an vital need...With the tomorrow release I prepared the first steps for a light dialog support based on Routing mechanism - complete FROM changing and restoring for the whole dialog was the prove of concept :). By being able to control the call from somewhere in the middle, I target especially issue no 2 and why not 4 and 5.
....and all this by avoiding the B2BUA.......
regards, bogdan
Greg Fausak wrote:
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
- homogenize the packets you see
- obscure your network/customers to gateways obscure gateways to your customers
- reduce packet size
- provide a handy spot to kill a call in progress
- and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
On 10/27/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Daryl Sanders wrote:
This is exactly what I am trying to overcome. Do third party PSTN providers typically employ any other means of monitoring a call? I would think the would automatically disconnect the call after a certain amount of time if there was no media detected.
Yes they should - but there a thousands of GW providers which have no glue about their equipment :-(
klaus
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
Bogdan, can you give us more details of your plans?
We have to decide how to deal with the problem of killing a call in progress and detect an hunged-up call.
I'd like to avoid the use of a B2BUA, so I'd like to know if, when and how you plan to obtain this. I really cannot understand how you will achieve this simply with a SER module. You need some way to store all the data of dialogs in progress... Don't you?
Thanks.
Bogdan-Andrei Iancu wrote:
Hi Greg,
keeping the call control on your hands is an vital need...With the tomorrow release I prepared the first steps for a light dialog support based on Routing mechanism - complete FROM changing and restoring for the whole dialog was the prove of concept :). By being able to control the call from somewhere in the middle, I target especially issue no 2 and why not 4 and 5.
....and all this by avoiding the B2BUA.......
regards, bogdan
Greg Fausak wrote:
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
- homogenize the packets you see
- obscure your network/customers to gateways obscure gateways to your customers
- reduce packet size
- provide a handy spot to kill a call in progress
- and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
Hi Federico,
at this point the whole design is still on the drawing board - I still have to figure out some of things before starting the implementation. Yes some dialog information will be kept on the proxy. As mentioned, the first outcome will be solving the points 2 and 3 and then the 4 and 5 (see Greg's list).
regards, bogdan
Federico Giannici wrote:
Bogdan, can you give us more details of your plans?
We have to decide how to deal with the problem of killing a call in progress and detect an hunged-up call.
I'd like to avoid the use of a B2BUA, so I'd like to know if, when and how you plan to obtain this. I really cannot understand how you will achieve this simply with a SER module. You need some way to store all the data of dialogs in progress... Don't you?
Thanks.
Bogdan-Andrei Iancu wrote:
Hi Greg,
keeping the call control on your hands is an vital need...With the tomorrow release I prepared the first steps for a light dialog support based on Routing mechanism - complete FROM changing and restoring for the whole dialog was the prove of concept :). By being able to control the call from somewhere in the middle, I target especially issue no 2 and why not 4 and 5.
....and all this by avoiding the B2BUA.......
regards, bogdan
Greg Fausak wrote:
ya, that's been my experience too. it's a bit embarrassing to send your customer a bill for 18000 minutes on a single call...even if the gw operator doesn't bill you, you bill your customer, right?
i am very interested in a b2bua project. they just come in handy for all sort of stuff.
it is overkill for just terminating calls. they have other benefits as well...
- homogenize the packets you see
- obscure your network/customers to gateways obscure gateways to your customers
- reduce packet size
- provide a handy spot to kill a call in progress
- and my favorite, hung call detection
unfortunately, none of these benefits is large enough to convince some people that a b2bua is needed.
-g
Can the session-timer be changed by the UAC
Iqbal
Greg Fausak wrote:
The re-INVITEs definitely work. I run some setups with Jasomi inline (a commercial inline b2bua). I configure them to reINVITE, works like a charm. If the reINVITE isn't answered (in either direction) the Jasomi sends BYEs in both directions. I believe other commercial gear works that way.
Also, I believe Session-Timers are supported by Cisco gateways, but I don't have experience with those.
-g
On 10/27/05, Daryl Sanders daryl.sanders@gmail.com wrote:
Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers.
- Daryl
On 10/27/05, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
by sending re-INVITEs from the middle of the path you will increase the cseq number differently on each side...so you will need to synchronize the cseq value when some in-the-dialog requests are passing through your proxy....and that's quite complicated....
regards, bogdan
Daryl Sanders wrote:
Would it be possible to fake a REINVITE then check the response to determine if a call is still in session? Just brainstorming...
- Daryl
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers
-- Greg Fausak greg@thursday.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
-
Bogdan-Andrei Iancu -
Daryl Sanders -
Federico Giannici -
Greg Fausak -
Iqbal -
Joachim Fabini -
Klaus Darilion