Re: [Asterisk-Dev] AST_FLAG_DEFER_DTMF (would like dialogic-r4like semantics)
On Thursday 01 December 2005 10:04, Greg Lim wrote: I got a couple of answers to my post, but no-one actually answered my question, namely: What does AST_FLAG_DEFER_DTMF do? Should be fairly simple. Don't deliver DTMF received from a particular channel, when you're in a certain section (like sending a coded message with DTMF), but instead queue that DTMF to be sent when that critical section is complete. -- Tilghman ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] meetme enhancements to improve efficiency
There was some talk a while back about making changes to the meetme application. I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Geoff ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
Geoff Karl wrote: I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Absolutely. ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
On 12/1/05, Kevin P. Fleming [EMAIL PROTECTED] wrote: Geoff Karl wrote: I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Absolutely. Kevin, you know the internals infinitely better than I do. Is this a major undertaking? thanks, Geoff ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
On Dec 1, 2005, at 4:22 PM, Geoff Karl wrote: On 12/1/05, Kevin P. Fleming [EMAIL PROTECTED] wrote: Geoff Karl wrote: I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Absolutely. Kevin, you know the internals infinitely better than I do. Is this a major undertaking? Why don't you just use app_conference? It might be easier to add the functionality you need to app_conference, than it would be to change the mixing architecture of meetme to be the same as app_conference. You can already add most of this functionality to app_conference, if you attach something to the manager interface: From the manager interface, app_conference will report each user's DTMF digits dialed, and will also allow you to, e.g. play sounds to users etc. The idea here has been to keep all the features out of app_conference, and move them out to the manager interface, where you can write them in a much simpler language (i.e. perl, or whatever is your favorite). -SteveK ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
On 12/1/05, SteveK [EMAIL PROTECTED] wrote: On Dec 1, 2005, at 4:22 PM, Geoff Karl wrote: On 12/1/05, Kevin P. Fleming [EMAIL PROTECTED] wrote: Geoff Karl wrote: I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Absolutely. Kevin, you know the internals infinitely better than I do. Is this a major undertaking? Why don't you just use app_conference? It might be easier to add the functionality you need to app_conference, than it would be to change the mixing architecture of meetme to be the same as app_conference. You can already add most of this functionality to app_conference, if you attach something to the manager interface: From the manager interface, app_conference will report each user's DTMF digits dialed, and will also allow you to, e.g. play sounds to users etc. The idea here has been to keep all the features out of app_conference, and move them out to the manager interface, where you can write them in a much simpler language (i.e. perl, or whatever is your favorite). -SteveK I have looked at app_conference many, many times and it looks great, but I really want to see something supported within Asterisk. Conferencing is a killer app and Asterisk itself should have a very good implementation. Geoff ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
On Dec 1, 2005, at 5:08 PM, Geoff Karl wrote: On 12/1/05, SteveK [EMAIL PROTECTED] wrote: On Dec 1, 2005, at 4:22 PM, Geoff Karl wrote: On 12/1/05, Kevin P. Fleming [EMAIL PROTECTED] wrote: Geoff Karl wrote: I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Absolutely. Kevin, you know the internals infinitely better than I do. Is this a major undertaking? Why don't you just use app_conference? It might be easier to add the functionality you need to app_conference, than it would be to change the mixing architecture of meetme to be the same as app_conference. You can already add most of this functionality to app_conference, if you attach something to the manager interface: From the manager interface, app_conference will report each user's DTMF digits dialed, and will also allow you to, e.g. play sounds to users etc. The idea here has been to keep all the features out of app_conference, and move them out to the manager interface, where you can write them in a much simpler language (i.e. perl, or whatever is your favorite). -SteveK I have looked at app_conference many, many times and it looks great, but I really want to see something supported within Asterisk. Conferencing is a killer app and Asterisk itself should have a very good implementation. There's no technical reason why app_conference couldn't go inside asterisk. The code could be disclaimed, if people were interested in maintaining it in the core. It _is_ maintained, as I use it all the time, but there's actually a couple of issues which make it less than ideal at the moment: 1) It wants all users to have 20ms frames, and will not be happy otherwise (so, iLBC, etc are no good). 2) it doesn't include _any_ features. These can both be addressed, and it might be easier than trying to change the meetme architecture. (also, (2) can be done more cleanly than in meetme, because it can be external from the actual muxing functionality). I guess, you could also take the guts of app_conference, and transplant them into meetme (you'd still need the disclaimer), but then you'd still have all the muxing functionality mixed into the features.. -SteveK ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
I also agree that the conferense handeling in meetme is god but we can se the preformace problems. But as its a standard part of asterisk its very nice to have it in there and i would vote for meetme to be more optimised. Best regards jan --On Thursday, December 01, 2005 02:08:16 PM -0800 Geoff Karl [EMAIL PROTECTED] wrote: On 12/1/05, SteveK [EMAIL PROTECTED] wrote: On Dec 1, 2005, at 4:22 PM, Geoff Karl wrote: On 12/1/05, Kevin P. Fleming [EMAIL PROTECTED] wrote: Geoff Karl wrote: I would like to see something similar to app_conference where the transcoding occurs only once per codec. This will allow meetme to scale much better. Is there any interest in this? Absolutely. Kevin, you know the internals infinitely better than I do. Is this a major undertaking? Why don't you just use app_conference? It might be easier to add the functionality you need to app_conference, than it would be to change the mixing architecture of meetme to be the same as app_conference. You can already add most of this functionality to app_conference, if you attach something to the manager interface: From the manager interface, app_conference will report each user's DTMF digits dialed, and will also allow you to, e.g. play sounds to users etc. The idea here has been to keep all the features out of app_conference, and move them out to the manager interface, where you can write them in a much simpler language (i.e. perl, or whatever is your favorite). -SteveK I have looked at app_conference many, many times and it looks great, but I really want to see something supported within Asterisk. Conferencing is a killer app and Asterisk itself should have a very good implementation. Geoff ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- +--- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: [EMAIL PROTECTED] ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Very Weird problem with MeetMe, SIP, Zap and the combo of the three
Hi All, I have a really funky problem, which I can't seem to pin point.I have a setup that looks something like this: SS7 Networks --SS7-- Veraz IGate4000 --SIP-- Asterisk Now, Asterisk has a second connection, that looks like this: Asterisk --PRI-- Avaya CTI Now, I'll describe several sceanrios that I'm testing, with some really Weird results: Scenario 1: A. User calls in from the SS7 network, via SIP to Asterisk. B. Asterisk originates a call to Avaya CTI via PRI C. Both users are now put into a MeetMe room D. Avaya user talks, SS7 user hears. SS7 user talks, Avaya heards nothing. Scenario 2: A. User calls in from the SS7 network, via SIP to Asterisk B. Asterisk dials out via the PRI to the Avaya to a specified location. C. Avaya picks up the call, then generates an outgoing call. D. The call is picked up. E. User at the avaya end speaks, SS7 user hears. User at SS7 speaks, avaya user doesn't hear. Scenario 3: A. User calls in from the SS7 network, via SIP to Asterisk B. Asterisk dials out via the SIP connection to a specified location. C. The call is being picked at the remote end and we have 2 way audio. Scenario 4: A. User 1 calls in from the SS7 network, and is put into MeetMe room 1000. B. User 2 calls in from the SS7 network, and is put into MeetMe room 1000. C. Users 1 and 2 talk, but can't hear a thing. Ok, now, I'll go through the conclusions I've reached: 1. There is no network blockage, which is proved by Scenario 3. 2. A test system, working with the same Asterisk version (1.2.0-stable) is working fine in a different location, with a slightly different setup. 3. Scenario 3 negates issues of SIP interoperability between Veraz and Asterisk, on the following tested codecs: g711, IPP-g723.1, IPP-g729 and Digium-g729 4. All MeetMe application entries ares started with: MqAx options. 5. Scenario 4 and the options defined in section 4 indicate the MOH should have been heared, but it wasn't. 6. Now, if I wouldn't have tested scenario 4, I would have said that the PRI is causing issues, however, scenario 4 indicates that something else is wrong. So, anyone has an idea of what's going on here? Or better yet, a proposed course of Action? Regards, Nir Simionovich ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] SIP handling of Contact header with new port
This is observed with 1.2.0, not CVS. When a sip peer that is behind NAT is invited, it returns a contact header with a port other than 5060 in it's 180 and 200 messages. For instance: -- Called otherguy/04082098516 ev02a*CLI -- SIP read from 1xx.yy.zz.aa:5060: SIP/2.0 100 Trying Call-ID: [EMAIL PROTECTED] Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK30bbe558;rport From: +13115552368 sip:[EMAIL PROTECTED];tag=as3a9d8dca To: sip:[EMAIL PROTECTED]:5060 CSeq: 102 INVITE Content-Length: 0 --- (7 headers 0 lines)--- ev02a*CLI -- SIP read from 1xx.yy.zz.aa:5060: SIP/2.0 180 Ringing Call-ID: [EMAIL PROTECTED] Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK30bbe558 From: +13115552368 sip:[EMAIL PROTECTED];tag=as3a9d8dca To: sip:[EMAIL PROTECTED]:5060;tag=0a94b5e7 CSeq: 102 INVITE Contact: sip:[EMAIL PROTECTED]:32801 Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, INFO Content-Disposition: session; handling=required Content-Type: application/sdp Content-Length: 164 v=0 o=Sonus_UAC 1383 25405 IN IP4 1xx.yy.zz.aa s=SIP Media Capabilities c=IN IP4 1xx.yy.zz.aa t=0 0 m=audio 32836 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv And then... --- (11 headers 8 lines)--- Found RTP audio format 0 Peer audio RTP is at port 1xx.yy.zz.aa:32836 Found description format PCMU Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw) Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing) -- SIP/otherguy-0c77 is ringing -- SIP/otherguy-0c77 is making progress passing it to SIP/64.156.10.50-097f01c0 ev02a*CLI -- SIP read from 1xx.yy.zz.aa:5060: SIP/2.0 200 OK Call-ID: [EMAIL PROTECTED] Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK30bbe558 From: +13115552368 sip:[EMAIL PROTECTED];tag=as3a9d8dca To: sip:[EMAIL PROTECTED]:5060;tag=0a94b5e7 CSeq: 102 INVITE Accept: multipart/mixed, application/sdp, application/isup, application/dtmf, application/dtmf-relay Contact: sip:[EMAIL PROTECTED]:32801 Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, INFO Content-Disposition: session; handling=required Content-Type: application/sdp Content-Length: 164 v=0 o=Sonus_UAC 1383 25405 IN IP4 1xx.yy.zz.aa s=SIP Media Capabilities c=IN IP4 1xx.yy.zz.aa t=0 0 m=audio 32836 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv Now, below, I see set_destination setting the destination port to 32801, but the next packet still sends to port 5060. --- (12 headers 8 lines)--- Found RTP audio format 0 Peer audio RTP is at port 1xx.yy.zz.aa:32836 Found description format PCMU Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw) Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing) list_route: hop: sip:[EMAIL PROTECTED]:32801 set_destination: Parsing sip:[EMAIL PROTECTED]:32801 for address/port to send to set_destination: set destination to 1xx.yy.zz.aa, port 32801 Transmitting (NAT) to 1xx.yy.zz.aa:5060: ACK sip:[EMAIL PROTECTED]:32801 SIP/2.0 Via: SIP/2.0/UDP 1aa.bbb.ccc.ddd:5060;branch=z9hG4bK29977c17;rport From: +13115552368 sip:[EMAIL PROTECTED];tag=as3a9d8dca To: sip:[EMAIL PROTECTED];tag=0a94b5e7 Contact: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 Shouldn't this switch to talking to port 32801? The sip.conf for this peer has nat=yes on it. [otherguy] type=friend host=1xx.yy.zz.aa context=otherguy disallow=all allow=ulaw insecure=very nat=yes Have I found a bug? /edg ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
Geoff Karl wrote: I have looked at app_conference many, many times and it looks great, but I really want to see something supported within Asterisk. Conferencing is a killer app and Asterisk itself should have a very good implementation. I too have looked at app_conference but will not run it in a production environment because it is not distributed with Asterisk. Jeremy McNamara ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
Jeremy McNamara wrote: Geoff Karl wrote: I have looked at app_conference many, many times and it looks great, but I really want to see something supported within Asterisk. Conferencing is a killer app and Asterisk itself should have a very good implementation. I too have looked at app_conference but will not run it in a production environment because it is not distributed with Asterisk. Jeremy McNamara I feel the same way. I've used it but I'm hesitant to get too deeply committed to it simply because it is not a standard part of asterisk... Darren Wiebe [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- Darren Wiebe [EMAIL PROTECTED] Aleph Communications ASTPP - Open Source Voip Billing Calling Cards www.aleph-com.net/astpp ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] New Jersey ATT Vocie T1 Asterisk Toll free not working
Hi, Alex: After taking your suggestion change from em to fxoks, it still did not work, and this time even calling to normal PSTN number also failed? Any more suggestion? Charles On Wed, 30 Nov 2005, Charles Huang wrote: span=1,0,0,esf,b8zs em=1-24 and in my /etc/asterisk/zapata.conf file, I set the following signalling=em group=1 channel=1-24 Can anyone give me any suggestion, this is really strange, how come some will succeed and some will fail. a) this is not a -dev question! b) have you asked whether the signaling is really em, or, more likely, it is fxo? -alex Message: 1 Date: Wed, 30 Nov 2005 21:19:21 -0800 From: Charles Huang [EMAIL PROTECTED] Subject: [Asterisk-Dev] New Jersey ATT Vocie T1 Asterisk Toll free number not working To: asterisk-dev@lists.digium.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi, All: I set up an Asterisk machine in our New Jersey Office which is using ATT Voice T1, I am facing one very strange problems. I can dial to any of the Normal PSTN numbers (including Cell phone numbers), but for Toll Free numbers, some of them are working, and some of them are not working. For example, the following Toll Free numbers are working and can dial from my SIP phone: 1-800-315-9339 1-866-562-6506 1-877-568-8746 but these numbers when I dial, I will only hear the rings when not set progess=yes option; if set the progess on zapata.conf, then I can hear from CO that this was fail. 1-888-848-4792 1-866-280-6429 1-866-825-5460 1-800-361-5659 In my /etc/zaptel.conf, I set the following span=1,0,0,esf,b8zs em=1-24 and in my /etc/asterisk/zapata.conf file, I set the following signalling=em group=1 channel=1-24 Can anyone give me any suggestion, this is really strange, how come some will succeed and some will fail. Thanks a lot! Charles ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] meetme enhancements to improve efficiency
I guess, you could also take the guts of app_conference, and transplant them into meetme (you'd still need the disclaimer), but then you'd still have all the muxing functionality mixed into the features.. Any particular reason why the author does not care to disclaim the code? -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] New Jersey ATT Vocie T1 Asterisk Toll free not working
On 12/1/05, Charles Huang [EMAIL PROTECTED] wrote: Hi, Alex: After taking your suggestion change from em to fxoks, it still did not work, and this time even calling to normal PSTN number also failed? Any more suggestion? Charles Is this a dedicated LD trunk or a DID PRI trunk from ATT? If a dedicated LD trunk, many carriers often don't let you dial another provider's 8XX numbers off of it. Please take this thread to the -users forum for additional feedback on it. BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [Asterisk-Dev] meetme enhancements to improve efficiency
There's no technical reason why app_conference couldn't go inside asterisk. The code could be disclaimed, if people were interested in maintaining it in the core. It _is_ maintained, as I use it all the time, but there's actually a couple of issues which make it less than ideal at the moment: 1) It wants all users to have 20ms frames, and will not be happy otherwise (so, iLBC, etc are no good). There's a patch in Mantis that addresses the 20ms issue in Meetme. It's likely not ideal, but functional. 2) it doesn't include _any_ features. These can both be addressed, and it might be easier than trying to change the meetme architecture. (also, (2) can be done more cleanly than in meetme, because it can be external from the actual muxing functionality). I guess, you could also take the guts of app_conference, and transplant them into meetme (you'd still need the disclaimer), but then you'd still have all the muxing functionality mixed into the features.. There's another patch in Mantis to start the task of making Meetme Realtime-enabled. The interest with this patch is it can be extended to support a scheduling and control process. I have been maintaining an out of tree module that checks scheduling and resource details and launchs app_meetme if all conditions are meet. I planned to merge these features into Meetme once Realtime support is in. In any case I would love to see either Meetme adopt some of app_conference's features or app_conference replace app_meetme. Dan ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
