[Asterisk-Dev] SS7 for *
Hadi Jadallah
hadi at audiotelecom.net
Sat Oct 2 08:22:42 MST 2004
Hi Steve,
Steve Wrote:
>If you want a GPL one, carry one. However, if you are prepared to pay,
>SS7 for * is now working.
Is there anybody I can contact regarding this? I am prepared to pay.
Yours,
Hadi.
-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of asterisk-dev-request at lists.digium.com
Sent: Friday, October 01, 2004 1:59 PM
To: asterisk-dev at lists.digium.com
Subject: Asterisk-Dev Digest, Vol 3, Issue 1
Send Asterisk-Dev mailing list submissions to
asterisk-dev at lists.digium.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
asterisk-dev-request at lists.digium.com
You can reach the person managing the list at
asterisk-dev-owner at lists.digium.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of Asterisk-Dev digest..."
Today's Topics:
1. qcall CDR problem (VoIP)
2. Re: ast_waitstream_full: Wait failed (Resource temporarily
unavailable) (Dinesh Nair)
3. Re: Call control problems from Java (Miroslav Nachev)
4. Re: Use the Meetme application with another module than
USB-UHCI (Arkadi Shishlov)
5. RE: Call control problems from Java (Zac Wolfe)
6. Re: Wish List / Brain Storm from AstriCon (Steve Underwood)
7. Re: Wish List / Brain Storm from AstriCon (Steve Underwood)
8. How is DTMF relayed? (Andreas Sikkema)
----------------------------------------------------------------------
Message: 1
Date: Fri, 1 Oct 2004 12:16:41 +0800
From: "VoIP" <voip at er21.com>
Subject: [Asterisk-Dev] qcall CDR problem
To: "'Asterisk Developers Mailing List'"
<asterisk-dev at lists.digium.com>
Message-ID: <ER-DNScKVOz9b1tvmC20000001a at er-dns.er21.com>
Content-Type: text/plain; charset="us-ascii"
Hi, I am trying to use qcall to do callback service. And put the qcall file as follows,
------------------------------------
SIP/2001 at b.com 1001 at a.com SIP/3001 at c.com 0
------------------------------------
Qcall first initiate a call to 2001 at b.com and wait for his answer, when 2001 at b.com answers the call, Qcall connects to 3001 at c.com. So 2001 and 3001
can talk to each other. Here we set the caller id to 1001 at a.com.
Actually there are 2 legs in this call. One is 2001 at b.com, and the other is 3001 at c.com. I found CDR only recorded call from 1001 at a.com to 3001 at c.com but no such CDR from 1001 at a.com to 2001 at b.com.
If 2001 at b.com and 3001 at c.com are both PSTN numbers, then it should be a big problem to charge the callback users.
Although this is a user level questions, I doubt the CDR mechanism should have problem.
Regds,
KK
------------------------------
Message: 2
Date: Fri, 01 Oct 2004 12:19:21 +0800
From: Dinesh Nair <dinesh at alphaque.com>
Subject: Re: [Asterisk-Dev] ast_waitstream_full: Wait failed (Resource
temporarily unavailable)
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <415CDAC9.3000708 at alphaque.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
On 01/10/2004 02:55 Gil Kloepfer said the following:
> I think I identified this problem a while back. If you guys would
> like me to repost this, I can...otherwise look for the message
> I sent with subject: Oddities in asterisk/say.c
excellent, gil. my first observation of the problem was voicemail hanging
up on me as well, which i then tracked down to the SayNumber application,
and further back to ast_waitstream_full().
your solution mirrors the observation (and solution) i posted as well.
so, based on your experience, it'd be ok to modify that snippet of code to
if (audiofd > -1 && ctrlfd > -1) in all places that it occurs in say.c ?
(the rest of the functions are just different language handling functions,
so theoretically it should be alright)
--
Regards, /\_/\ "All dogs go to heaven."
dinesh at alphaque.com (0 0) http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do |
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b." |
| done; done |
+=========================================================================+
------------------------------
Message: 3
Date: Fri, 1 Oct 2004 10:10:09 +0200
From: Miroslav Nachev <miro at space-comm.com>
Subject: Re: [Asterisk-Dev] Call control problems from Java
To: Asterisk Developers Mailing List
<asterisk-dev at lists.digium.com>(E-mail)
Message-ID: <05766962.20041001101009 at space-comm.com>
Content-Type: text/plain; charset=us-ascii
Dear Zac,
This is Great. We have ideas to replace most of the Asterisk
Services (modules) with Java too, but we haven't time yet. But in case
that you are start this job we will help you.
Because our idea was to use some Modules Convention which to
support independet language support what do you think to make first
some working plan and then to start working?
We are ready to share this hard job with you. Please say how can we
help you?
Best Regards,
Miroslav Nachev
First the good news: I've just released a Java (JNI) bridge to Asterisk
called, JAsterisk (ya I got a little creative with the name). It's
available at (http://sourceforge.net/projects/jasterisk/) and is pre-alpha.
It's currently distributed as a patch on the 1.0.0 source release but I hope
to have a version available soon that doesn't require any modifications to
Asterisk code.
Anyway, almost all Asterisk functionality is available and working fine from
Java. Almost...
I have some strange issues that I'm dealing with that hopefully won't seem
so strange to someone out there:
1. Call comes in, channel is routed to the "Safi" (Safi Systems is my
company's name) application which simply fires a callback to the JNI
notifying a Jasterisk application of it's presence, and loops while waiting
for channel hangup (like the wait_for_hangup function in app_dial.c). The
Jasterisk application then routes the call to "Jo Blo" at some address, by
executing the Asterisk "Dial" application in a new Java thread. When Jo
answers the call, caller and callee are connected and everything seems to be
OK. However, if Jo then tries to transfer the call (using '#' for Zaptel
or the 'Transfer' function for IAX channels), the caller and callee are
disconnected and the call dies. Why? If the caller calls Jo Blo directly
(as per usual) instead of being routed through the Jasterisk app, the
transfer works fine. Similar issues are noticed when parking redirected
calls.
2. pbx.c builtin functions "Transfer" and "Goto" don't work in Jasterisk
apps. The channel structure's members are correctly updated but the
extension or context switch never happens. What am I missing here?
This software is in it's very early stages and it's my goal to make it the
de-facto Java-->Asterisk interface. I'm very open to suggestions and if a
better approach is revealed I'll happily adjust or rewrite the thing from
scratch. Eventually I'd like to be able to forgo the Asterisk dialplan
entirely (except maybe for an exten => _.,1,Safi() catch-all), and handle
all call routing from Java, perhaps using a JTAPI interface or similar.
Progress is encouraging so far -- I've already deployed some pretty complex
production IVR's using this package and they're all stable and running fine.
However, these call routing related issues have me a little worried that I
may have taken a wrong turn somewhere.
Any ideas or recommendations? TIA
Zac Wolfe
Safi Systems LLC
zacw at safisys.com
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
------------------------------
Message: 4
Date: Fri, 1 Oct 2004 10:54:15 +0300
From: "Arkadi Shishlov" <arkadi at mebius.lv>
Subject: Re: [Asterisk-Dev] Use the Meetme application with another
module than USB-UHCI
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <20041001075415.GB7055 at mebius.lv>
Content-Type: text/plain; charset=us-ascii
http://www.voip-info.org/tiki-index.php?page=Asterisk%20timer
------------------------------
Message: 5
Date: Fri, 1 Oct 2004 03:49:41 -0700
From: "Zac Wolfe" <zacw at safisys.com>
Subject: RE: [Asterisk-Dev] Call control problems from Java
To: "'Miroslav Nachev'" <miro at space-comm.com>, "'Asterisk Developers
Mailing List (E-mail)'" <asterisk-dev at lists.digium.com>
Message-ID: <000901c4a7a4$5bf05a10$6601a8c0 at c910133a2>
Content-Type: text/plain; charset="us-ascii"
Hi Miroslav,
I'd *love* to have some help on this project but lets see if our goals are
in sync.
My overall goal is to develop a Java-based VXML/CCXML engine for Asterisk.
Achieving this requires that I have complete call control from Java.
Optimally, we could then do away with the Asterisk Dialplan entirely and do
everything via VXML/CCXML. The AGI interface is OK but for my application I
need fine-grained event-driven processes where we can track each call from
setup to tear-down and everything in between.
I've started building a JTAPI-like framework that sits on top of JAsterisk
that handles all the events and provides a high-level framework for building
telephony apps. But, as I described in my previous email, I'm dealing with
some nagging problems that I need to fix before I can complete this project.
You described the "module convention". Is it the Asterisk application API
you're referring to (ex app_dial,app_meetme,...)? If so, I think Jasterisk
may be able to do what you're talking about already (or with some minor
additions). BTW, The version of JAsterisk i'm working on now allows you to
start the JVM from Asterisk or to start Asterisk from the JVM (which is the
way it's set up currently).
Anyway, lets explore some more and see if we can work together on this.
I hope I'm making sense -- it's 4am where I am.
Zac
-----Original Message-----
From: Miroslav Nachev [mailto:miro at space-comm.com]
Sent: Friday, October 01, 2004 1:10 AM
To: Asterisk Developers Mailing List (E-mail)
Subject: Re: [Asterisk-Dev] Call control problems from Java
Dear Zac,
This is Great. We have ideas to replace most of the Asterisk
Services (modules) with Java too, but we haven't time yet. But in case
that you are start this job we will help you.
Because our idea was to use some Modules Convention which to
support independet language support what do you think to make first
some working plan and then to start working?
We are ready to share this hard job with you. Please say how can we
help you?
Best Regards,
Miroslav Nachev
First the good news: I've just released a Java (JNI) bridge to Asterisk
called, JAsterisk (ya I got a little creative with the name). It's
available at (http://sourceforge.net/projects/jasterisk/) and is pre-alpha.
It's currently distributed as a patch on the 1.0.0 source release but I hope
to have a version available soon that doesn't require any modifications to
Asterisk code.
Anyway, almost all Asterisk functionality is available and working fine from
Java. Almost...
I have some strange issues that I'm dealing with that hopefully won't seem
so strange to someone out there:
1. Call comes in, channel is routed to the "Safi" (Safi Systems is my
company's name) application which simply fires a callback to the JNI
notifying a Jasterisk application of it's presence, and loops while waiting
for channel hangup (like the wait_for_hangup function in app_dial.c). The
Jasterisk application then routes the call to "Jo Blo" at some address, by
executing the Asterisk "Dial" application in a new Java thread. When Jo
answers the call, caller and callee are connected and everything seems to be
OK. However, if Jo then tries to transfer the call (using '#' for Zaptel
or the 'Transfer' function for IAX channels), the caller and callee are
disconnected and the call dies. Why? If the caller calls Jo Blo directly
(as per usual) instead of being routed through the Jasterisk app, the
transfer works fine. Similar issues are noticed when parking redirected
calls.
2. pbx.c builtin functions "Transfer" and "Goto" don't work in Jasterisk
apps. The channel structure's members are correctly updated but the
extension or context switch never happens. What am I missing here?
This software is in it's very early stages and it's my goal to make it the
de-facto Java-->Asterisk interface. I'm very open to suggestions and if a
better approach is revealed I'll happily adjust or rewrite the thing from
scratch. Eventually I'd like to be able to forgo the Asterisk dialplan
entirely (except maybe for an exten => _.,1,Safi() catch-all), and handle
all call routing from Java, perhaps using a JTAPI interface or similar.
Progress is encouraging so far -- I've already deployed some pretty complex
production IVR's using this package and they're all stable and running fine.
However, these call routing related issues have me a little worried that I
may have taken a wrong turn somewhere.
Any ideas or recommendations? TIA
Zac Wolfe
Safi Systems LLC
zacw at safisys.com
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
------------------------------
Message: 6
Date: Fri, 01 Oct 2004 19:40:35 +0800
From: Steve Underwood <steveu at coppice.org>
Subject: Re: [Asterisk-Dev] Wish List / Brain Storm from AstriCon
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <415D4233.3050507 at coppice.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Steven Sokol wrote:
>37) R2 Integration (along with SS7 and QSIG).
>
>
R2 support has now been released as GPL code. SS7 is now working at a
test site in Germany, though is unlikely to become GPL any time soon. It
is currently carrying small scale non-fee paying traffic, while its
stability is being assessed. This is a fresh implementation of SS7,
owing nothing to implementations like OpenSS7.
>[...]
>
>39) Move from GLIB C to MicroLib C for better support of embedded systems.
>
>
Shouldn't that be support uLIBC as well, rather than instead? Excellent
idea. Threading seems to screw up when using uLIBC right now. That seems
to be the only thing stopping me from running a stripped down * on
Linksys boxes.
>40) T.38 fax support over Asterisk (pass-through).
>
>
Passthrough should be possible using the T38modem code in H.323. Some
work is needed, but I doubt its that much.
>41) What happened to SpanDSP? Steve Underwood. Had to drop the project.
>May pick it back up again.
>
>
Eh? It has been in continuous active development. The April release has
been pretty stable, so I haven't had cause to keep releasing small
increments. A pre-release of the next major step was made available for
download this week. I suggest only serious testers play with it.
>42) Steve Underwood may be working on R2? Working on Class 1 and 2 support
>in his Span DSP. He is looking for support (financial and/or technical).
>
>
R2 is released. Class 1 is being worked on, at a low priority. Class 2
is pointless, as HylaFax can do all that stuff for you. I am not looking
for financial support, though a MacLaren F1 would be nice :-). If anyone
wants to push the class 1 implementation forward, they are most welcome to.
>[...]
>SNMP support for Asterisk.
>
>
That would be valuable.
>Voice quality monitoring?
>
>
That is hard, and the standardised methods - the ones most people will
accept - seem to have some IP issues. I tend to think most of the
results they achieve are rather bogus, anyway.
>Frame slip warnings and more across SNMP. Essentially alarm forwarding as
>SNMP.
>
>
An *excellent* idea. However, I remain unconvinced the current software
actually detects slips properly. I am implementing the ITU BERT specs
right now, to try to provide a proper end-to-end platform for this. The
T1/E1 framer chips support BERT tests, but a test to the application
level is what is really needed.
Regards,
Steve
------------------------------
Message: 7
Date: Fri, 01 Oct 2004 19:50:58 +0800
From: Steve Underwood <steveu at coppice.org>
Subject: Re: [Asterisk-Dev] Wish List / Brain Storm from AstriCon
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <415D44A2.8040203 at coppice.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Steven Sokol wrote:
>10) IBM's open-source speech recognition software
>
>
>
IBM haven't released any. What they released is just a few components
related to recognition.
>11) Intel's soft-DSP chips for some advanced management of media streams.
>
>
What do you mean by Intel soft-DSP chips?
>12) Dynamic routing protocol - ARP (Asterisk Routing Protocol). Dynamic
>extension - (ENUM).
>
>
ARP is a bad name, since ARP is already a core networking protocol.
>13) Voice frame size available in chunk sizes beyond 20ms.
>
>
Do you mean within *, or only for batching in larger packets. The former
seems bad. The latter a good idea.
>[...]
>
>15) Certification program for Asterisk - hardware and software. Additional
>approvals in other markets.
>
>
This is an interesting area, and will probably require lockdown of
modules, so they cannot be modified without raising an alarm "NON
APPROVED CODE RUNNING" or somesuch. The ISDN4Linux guys came up with
something like that, which has been acceptable to the approvals body in
the EU.
>16) IAX2 standards track - RFC submission
>
>
A good idea.
>17) Assembler coding of codec handlers for improved performance.
>
>
A wacky idea :-\ Making use of SIMD can help in some areas, though.
Algorithmic changes usually get you the biggest gains, but you might hit
some patent issues (no, not US only software patents).
>[...]
>22) QSIG - Help people migrate to Asterisk. (Q931 can help cover some
>additional channel functions).
>
>
Someone has done some work on QSIG in an extended libpri, but put it
aside. It might be resurrected.
>34) Additional video codecs. More than H261, H263.
>
>35) SS7 Support for Asterisk. Malcolm will set up a mailing list. A new
>development group is forming. Email: asterisk-ss7 at flanet.net
>
>
If you want a GPL one, carry one. However, if you are prepared to pay,
SS7 for * is now working.
Regards,
Steve
------------------------------
Message: 8
Date: Fri, 1 Oct 2004 13:59:07 +0200
From: "Andreas Sikkema" <andreas.sikkema at ritstele.com>
Subject: [Asterisk-Dev] How is DTMF relayed?
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Message-ID: <34F1B1EDB3E7B04C9A282FE3537FC49F141A3E at mail.ritstele.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I'm looking into DTMF relaying of Asterisk, specifically the
RFC 2833 relaying, but I'm not sure I understand where
the outgoing messages are sent.
In rtp.c ast_rtp_read() calls process_rfc2833(), which can
call send_dtmf(). From there the results of send_dtmf() are
returned back to ast_rtp_read().
When ast_rtp_read() receives this result, it checks if
rtp->callback is set and calls the callback function if
available.
I think this callback can be a function that really sends
the mesage to the other party, but I'm not sure. Can
someone enlighten me?
--
Andreas Sikkema Rits tele.com
Scheepmakersstraat 11 3011 VH Rotterdam
t: +31 (0)10 2245544 f: +31 (0)10 2245540
------------------------------
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
End of Asterisk-Dev Digest, Vol 3, Issue 1
******************************************
More information about the asterisk-dev
mailing list