Re: [asterisk-users] T.38 - Which endpoint shall reINVITE ? caller or callee ?
Olivier wrote: Hi, I've been playing with T.38. I observed that mostly but not always, it's the calling endpoint that reINVITE the other party to drop current SIP/G711 session and start a new T.38. But sometimes, it's also the callee party that reINVITE the calling party. Which is the standardized or most common, way to start a T.38 session ? Shall it come from callee or from caller ? Regards Fax transmission can be initiated from any one of the parties. AFAIK T.38 as well as the PSTN fax standards do not show any preference whether fax transmission is requested from a or b party. In practice, the caller usually initiates a fax transmission, but this doesn't mean that the called party cannot initiate it, too. Best regards, Vlasis Hatzistavrou. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] T.38 - Which endpoint shall reINVITE ? caller or callee ?
Vlasis Hatzistavrou (KTI) wrote: Fax transmission can be initiated from any one of the parties. AFAIK T.38 as well as the PSTN fax standards do not show any preference whether fax transmission is requested from a or b party. In practice, the caller usually initiates a fax transmission, but this doesn't mean that the called party cannot initiate it, too. Best regards, Vlasis Hatzistavrou. Steve Underwood wrote: Hey, why bother looking at a spec when its so much more fun to make it up as we go along? ... Regards, Steve I don't think there is a need to be ironic here... I wrote AFAIK which we all know means as far as I know, so why the bashing? ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] T.38 - Which endpoint shall reINVITE ? caller or callee ?
Olivier wrote: 2009/3/17 Vlasis Hatzistavrou (KTI) vh...@kinetix.gr mailto:vh...@kinetix.gr Vlasis Hatzistavrou (KTI) wrote: Fax transmission can be initiated from any one of the parties. AFAIK T.38 as well as the PSTN fax standards do not show any preference whether fax transmission is requested from a or b party. In practice, the caller usually initiates a fax transmission, but this doesn't mean that the called party cannot initiate it, too. Best regards, Vlasis Hatzistavrou. Steve Underwood wrote: Hey, why bother looking at a spec when its so much more fun to make it up as we go along? ... Regards, Steve I don't think there is a need to be ironic here... I wrote AFAIK which we all know means as far as I know, so why the bashing? Vlasis, I don't think Steve's irony where targeted to you but to those which are supposed to read specs (ATA vendors) ... Hello Olivier, Well, since Steve's comment followed right after my reply, it seemed like the comment was very much targeted at me... The comment can be taken both ways I guess... Regards, Vlasis. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] T.38 - Which endpoint shall reINVITE ? caller or callee ?
Steve Underwood wrote: Oh, it was meant for him. In the time it took him to write his wrong e-mail he could have gone to the ITU web site, downloaded a free copy of the T.38 spec, looked up the annex where it described the negotiation process, and found a clear statement of what is supposed to happen. Of course, that wouldn't tell him the real world issues, like the fact half the T.38 implementations out there don't follow the spec., but it would have been a valuable start. It would also keep the noise level on this list down. What a lot of people don't allow for when writing garbage is it stays on the internet for years, and eventually becomes reference material. :-\ Regards, Steve Does AFAIK mean anything at all to you? I never implied that I am the ultimate authority on fax. It has been many years since I read T38 or any other fax specs and apparently I don't remember them to the letter (hence the AFAIK in my sentence). Reference material? Really? My reply on a mailing list can hardly be mistaken for an ITU spec. The fact that my email will remain on the internet for years cannot justify your obnoxious behavior either, unless you honestly believe that my post will misguide the future generations of VoIP implementors for years to come... In other words, if you really wanted to correct my mistake you could have just said that I was wrong. I would even have thanked you for pointing out my error. In such a scenario you would have really contributed against the noise on this list. But unfortunately, all you did was come out as just another wise-guy who desperately needs to get off his high horse. Cheers, Vlasis. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Country numbering plan resources
For informational purposes many people find ITU's web site useful, although not always as detailed as one would probably want: http://www.itu.int/itu-t/inr/nnp/index.html It even has event dates of official numbering plan changes. Best regards, Vlasis Hatzistavrou Kinetix Tele.com International Inc. 306 Victoria House, Victoria, Mahe, Seychelles Tel.: +302310556134 Fax: +302310556134 (ext. 0) GSM: +306977835653 e-mail: vh...@kinetixtele.com http://www.kinetixtele.com Postal address: Monastiriou 9 Enotikon 54627 Thessaloniki Greece ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
Hello Andy, But, wouldn't it be better if you could ignore the CDR's completely and use an event based system? This would give you ALL the information you need. All that remains is to filter out the un-required bits. I'd disagree. In some cases a event based system would be the best solution, but in systems with high call volumes, scanning through events looking for the proper billing information and parsing them would be a hard job compared to CDRs. In most cases where there are no transfers, calls on hold etc, but only basic dial-in dial-out operations, using events instead of CDRs would probably be an overkill. Like I said earlier - the CDR's aren't reliable enough for a billing platform (as you've rightly pointed out) but are OK for very basic call logging (something the customer can look at). I'm not sure I understand what you mean exactly. If you have in mind cases of transfers, calls on hold etc and you refer to Asterisk's CDRs at this point in time, then indeed, Asterisk's CDRs are not reliable in many cases. However, CDRs in general on other platforms tend to be very reliable and useful for billing. My opinion is to transform Asterisk's CDR capabilities to something more carrier-grade in mind, configurable by the user. Best regards, Vlasis Hatzistavrou. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grey Man Sent: 05 December 2008 09:37 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] CDR Design On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas [EMAIL PROTECTED] wrote: In summary: Leave CDR exactly as it is and create a new CEL (Call Event Logging) module (optional in modules.conf) that puts out (and does not accept) call event information (ie. a one-way fire-and-forget output from Asterisk). Hi Andrew and Others, This thread is actually part of a discussion that has been going on for over a year. The links below provide the background to the whole thing. http://www.asterisk.org/node/48358 http://bugs.digium.com/view.php?id=11849 http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.htm l Up until recently the approach was to try and fix the specific bugs with transfer CDRs as a typical bug. There is now a realisation that that is a lot trickier than inially thought so it's been decided to try and come up with a good design for the Asterisk CDR sub-system. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
Hello, Andrew Thomas wrote: I'd disagree. In some cases a event based system would be the best solution, but in systems with high call volumes, scanning through events looking for the proper billing information and parsing them would be a hard job compared to CDRs. That's just it - you wouldn't be 'scanning' any CDR's - you'd be given Events. Your 3rd party app could then do anything it wanted to with them. Events are real time - not historic (like CDR's). Events are presented as they happen (hold, ring, etc) - CDR's are usually presented AFTER the call has finished so you miss things like hold-times etc. Indeed, if you refer to real time events then this is the way to go. However, many people (including our company) use CDRs as a fall back in case we don't have real-time billing data available. We use real time information for prepaid customers and stats, but we also crosscheck this data with CDRs periodically. I agree that both approaches would be useful in many different scenarios for different users. It would be ideal if both approaches could be implemented. Best regards, Vlasis Hatzistavrou. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
Andrew Thomas wrote: Quote : I couldn't disagree more. The CDRs is the MOST reliable source for billing purposes ...at the moment. Have you read about Greyman's transfer problem? If you are billing customers purely on the CDR output from Asterisk - then good luck to you :). This is exactly our point in this discussion. :):) We can't bill relying on Asterisk's CDRs at this moment, this is why we use a third party SBC to do real time billing stats, as well as collect CDRs from the SBC off-line for cross-checking with the live data. And this is why we support the opinion that Asterisk's CDRs should be expanded. Best regards, Vlasis Hatzistavrou. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] OT - Is sourceforge OpenH323 active ?
As I recall, when openh323.org because obsolete people could download the PWLib OpenH323 libraries from http://www.voxgratia.org/ Openh323 has moved to become OPAL (supporting SIP, H323 and IAX) and can be downloaded from http://www.opalvoip.org H323Plus is also a continuation of OpenH323 supporting only H323. If you need to download OpenH323 and PWLib version suitable for Asterisk's chan_h323 you can follow the OpenH323 downloads link at the Voxgratia site. I hope this helps. Best regards, Vlasis Hatzistavrou. Kinetix Tele.com International Inc. 306 Victoria House, Victoria, Mahe, Seychelles Tel.: +302310556134 Fax: +302310556134 (ext. 0) GSM: +306977835653 e-mail: [EMAIL PROTECTED] http://www.kinetixtele.com Postal address: Monastiriou 9 Enotikon 54627 Thessaloniki Greece Olivier wrote: Hi, A glance at sourceforge.net/projects/openh323 http://sourceforge.net/projects/openh323 Help Forum made me wonder if this location is the one to use (I got trouble in the past when google pointed to an obsolete site) : some quite old messages remain unanswered. Cheers ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AGI and prepaid billing + Radius
Yes, of course you can. We have used Perl and Authen::Radius in the past to create AGI calling card scripts to do AAA against RADIUS servers. Not only that, but we used it for routing the outgoing calls also in many cases. Best regards, Vlasis Hatzistavrou. bilal ghayyad wrote: Yes it answer and big thanks. I have another question (which might be not related alot to AGI) if u can help me: If Asterisk support Radius, so we can build Prepaid Billing with Radius to communicate via Radius as standard communication method? Regards Bilal --- On Tue, 9/23/08, Benjamin Jacob [EMAIL PROTECTED] wrote: From: Benjamin Jacob [EMAIL PROTECTED] Subject: Re: [asterisk-users] AGI and prepaid billing To: asterisk-users@lists.digium.com, [EMAIL PROTECTED] Date: Tuesday, September 23, 2008, 6:39 AM Hi Bilal, Yes it is definitely possible. And I've done it myself for a couple of our clients. Does that answer your two questions? cheers - Ben. --- On Tue, 9/23/08, bilal ghayyad [EMAIL PROTECTED] wrote: From: bilal ghayyad [EMAIL PROTECTED] Subject: [asterisk-users] AGI and prepaid billing To: asterisk-users@lists.digium.com Date: Tuesday, September 23, 2008, 9:52 AM Hi All; Did anyone do an prepaid billing application via AGI? I would like to know if that is possible. Regards Bilal ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] chan_h323 requirements
Hello, To compile chan_h323 as is distributed you need to download OpenH323 v1.18.0 and PwLib v1.10.0 from: http://www.voxgratia.org Some months ago I had made a patch to compile the 1.4.x version and the trunk version (which evolved to 1.6.x) with H323+. Sadly, the patch was not included in the 1.6.x version which is being released soon. So, for the time being you need to use the above versions from Voxgratia. Best regards, Vlasis Hatzistavrou. Bruce McAlister wrote: Hi All, I would just like to clarify the requirements of the h323 channel within asterisk. Can I use a recent edition of PTLib and OpenH323, for example, the editions located at OpenH323+: http://www.h323plus.org/source/ OpenH323+ v1.20.2 PTLib v2.0.1 Or do I need to use the versions at the original, now defunct, OpenH323 website: http://www.openh323.org/ OpenH323 v1.12.2 PWLib v1.5.2 I am hoping to build this for Asterisk 1.4.18 running on Solaris 10. Thanks Bruce ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] chan_h323 requirements
Hello Bruce, Bruce McAlister wrote: Did your patch for building with OpenH323+ make it into the 1.4 edition of Asterisk? No, it didn't as it was considered a new feature and by Digium's policy new features can only be added in the trunk versions. The strange thing is that I added it in trunk version, too, but it didn't make it in the upcoming 1.6 version either. Best regards, Vlasis Hatzistavrou ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DS3 Interface
Patrick wrote: On Tue, 2007-10-09 at 10:14 -0400, Matt wrote: Before you put any work into this... ask yourself... what exactly are you hoping to accomplish? I can imagine it be used as a TDM-SIP gateway but if I needed such a box I'd rather go for a Lucent MaxTNT, Lucent APX8000 or a Cisco 5xxx or look at FreeSWITCH which by design seems more suitable for these kind of high performance applications. There is no way one system can handle a DS3s worth of traffic... therefore, what good would this do? Why wouldn't today's powerful quadcore servers with Gigabit Ethernet interfaces not be able to handle less than 100Mbit/s synchronous traffic? Please enlighten me as I am no expert here. Regards, Patrick Perhaps it could also be used as a pure TDM switch with no VoIP calls involved? Best regards, Vlasis Hatzistavrou. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
