[Home]

Summary:ASTERISK-11957: [branch] Receiving Text from res_jabber
Reporter:Mahmoud (eech55)Labels:
Date Opened:2008-05-02 00:38:51Date Closed:2010-05-20 20:14:21
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_jabber/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) jabber.txt
( 1) jabber-broken1.txt
( 2) trunk-12569-1.diff
( 3) trunk-12569-2.diff
( 4) trunk-12569-3.diff
( 5) trunk-12569-4.diff
Description:Hello,

So far, chan_gtalk sends text to GTalk clients only. There is no way to hear input from them which limit us a lot.

It will be awesome if we are able to receive text from GTalk users, to provide extra services such as:

1) Voice menus. The user can select menus by sending corresponding keys
2) Or, "text" menus by which the chan_gtalk replies by text messages instead of voice

I am glad that phsultan thought about it, however very disappointed that it was canceled. http://bugs.digium.com/bug_view_advanced_page.php?bug_id=8659



****** ADDITIONAL INFORMATION ******

A branch for testing the JabberReceive application is available here :
http://svn.digium.com/svn/asterisk/team/phsultan/jabberreceive

Asterisk's SVN trunk is merged in this branch on a regular basis (every hour).

To install it :
# svn co http://svn.digium.com/svn/asterisk/team/phsultan/jabberreceive jabberreceive
# cd jabberreceive
# ./configure
# make
# make install
Comments:By: Brandon Kruse (bkruse) 2008-05-02 09:19:11

This seems like a feature request.

Could you update the patches and do some testing? (as that was the reason the original one was closed)
By: Mahmoud (eech55) 2008-05-02 21:16:12

I can, for sure, do testing (applying patches, compiling, and using it).

I would love to code as well. However, as  programming is not my profession, I may require more energy and time in the short run as I'll have many basic questions. So it would be more productive, for all of us, if I don't code.


By: phsultan (phsultan) 2008-05-03 16:53:48

eech55, I'll send a new patch by the end of the week. I'll be happy to have your feedback then.
By: Mahmoud (eech55) 2008-05-03 17:51:38

Philippe Sultan, glad to hear from you :) I'll test and feedback.
By: phsultan (phsultan) 2008-05-06 04:44:59

Ok the attached patch is a first step.

Here is a dialplan example of how to use it :
context gtalk-in {
s => {
 Answer();
 SendText("Please enter the extension you which to call");
 JabberReceive(NEW);
 Dial(SIP/${NEW}@10.0.0.1);
 Hangup();
}
};

Of course, the remote GoogleTalk client must place a call to Asterisk, which in return will answer the call, and interact with the user through a text chat. In the previous example, the user is expected to enter an extension that Asterisk will eventually use to place a call to a SIP peer.
By: phsultan (phsultan) 2008-05-06 07:25:15

Patch applies to SVN trunk.
By: Mahmoud (eech55) 2008-05-09 16:02:33

Thanks phsultan, great effort :-)


It worked perfectly without trouble. All hunks and compilation went smoothly, without the need of manual attention.

There were issues, however, they existed before I applied the patch as well. These issues didn't exist with version 1.4.19.1.

Basically, calls from GTalk toward any SIP phone and JabberReceive work as expected. For example, I'm able to serve voice menus and receive input text (DTMF) from the GTalk user and place calls accordingly. The problem resides when others (SIP/IAX as I tested) are calling GTalk users.

The 1st thing is, when a GTalk user is ringing a SIP or IAX2 phone, and the latter rejects the call, the GTalk user doesn't detect it, and no OUTGOING Jabber XML messages are displayed in Asterisk's CLI (so I assume Asterisk doesn't send any kind of notification to GTalk users in such condition). When the SIP/IAX2 phone accepts the call, it works fine, however it shows two notices (I've added new lines for sake of visibility):

[May 10 00:50:51] NOTICE[97664]:
chan_gtalk.c:1454 gtalk_indicate: Don't know how to indicate condition '-1'
[May 10 00:50:51] NOTICE[97664]:
chan_gtalk.c:1454 gtalk_indicate: Don't know how to indicate condition '20'


Another issue issue is, when a SIP phone calls an extension that evolves dialing a GTalk account (e.g. exten =>123,1,dial(Gtalk/asterisk/foo@gmail.com)),  the call goes down immediately and shows "service or option unavailable" (as Zoiper shows)

IAX account, keeps showing "Dialing", however no dial tune is heard. Tested with Zoiper as well.

On the GTalk account side. GTalk doesn't ring, however, a conversation window opens. The weird thing is that the conversation window doesn't include any text messages.

On Asterisk's CLI side, it shows the usual JABBER conversation in XML format, which basically says "error, bad-request, unknown session" in the last INCOMING message that Asterisk received. The complete conversation is here http://tinyurl.com/66tbum.

Please let me know if you need more input.


Kind regards,
M. Khonji


By: phsultan (phsultan) 2008-05-09 16:58:48

MAhmoud, thanks for your feedback. Before I dig further into the issues you've mentioned, can you post the relevant parts fo your jabber.conf, gtalk.conf and extensions.conf files? A console debug output will help too.

Thanks again!
By: phsultan (phsultan) 2008-05-10 03:20:41

From the debug you posted, Asterisk is not offering any codec to the GoogleTalk (client the payload-type XML tag is empty).

You should insert at least one codec, for example :

[guest]
context=gtalk-in
disallow=all
allow=ulaw


By: Mahmoud (eech55) 2008-05-11 17:42:18

Hello phsultan, Thanks for waiting.


I had "allow=all", which is (as I know) fine with other channels' configs (e.g SIP, IAX2). However, it didn't work. Nor multiple explicitly allowed codecs worked (empty "payload-type" was sent)

The only way of having "payload-type" set, as worked with me, was to have the "disallow=all" line.

When I added "disallow=all \n allow=ulaw", it worked fine. Which means, I can call GTalk users from SIP/IAX and the problem is solved. Thanks a lot phsultan :-) This solves all my GTalk related issues.

Not sure if you want to look at my configs (as the early problems are solved), but here they are anyways
jabber.conf - http://sial.org/pbot/31007
gtalk.conf - http://sial.org/pbot/31008
extentions.conf - http://sial.org/pbot/31011

In summary, chan_gtalk and res_jabber are working as expected, no issues so far. However, from an end user's perspective, I would prefer to have "allow=all" working, just as it does with sip.conf or iax.conf.

I have other issues, which are irrelevant to chan_gtalk/res_jabber. I'm using SVN-trunk-r115569M. DTMF (both info and rfc2833) doesn't work with some SIP clients (Zoiper and an old version of eyeBeam), while DTMF does work with SPA-3102's SIP. Asterisk 1.4.1 used to work fine with the previously mentioned SIP clients. I also experienced cases of asterisk crashes. So far I am uncertain about the causes yet. I will update to a more recent SVN and submit another bug case regarding SIP and the Asterisk stability the moment I understand the cause in a more accurate manner.

Please let me know if you need more input. And thanks again phsultan :-)


Kind regards,
M. Khonji


By: phsultan (phsultan) 2008-05-13 12:44:52

> In summary, chan_gtalk and res_jabber are working as expected, no issues so far.
> However, from an end user's perspective, I would prefer to have "allow=all"
> working, just as it does with sip.conf or iax.conf.

Ok, I'll try to address that issue. Regarding the DTMF problem, I won't have much time to dedicate to it, sorry Mahmoud.

I'd like you to test this new version of the patch. This new version does not look for the channel to queue the text frame to based on the caller id. This allows to use the JabberReceive application for any channel (SIP, IAX, ..), not only Gtalk or Jingle. I also added another argument so the administrator must specify the Jabber ID Asterisk should expect an XMPP message from.

A new dialplan snippet :
context acontext {
   s => {
     Answer();
     SendText("Please enter the extension you which to call");
     JabberReceive(philippe.sultan@gmail.com,NEW);
     Dial(SIP/${NEW}@10.0.0.1);
     Hangup();
   }
};

Mahmoud, can you please test this new version?

Thanks!
By: ph (ph) 2008-05-14 13:43:46

New Patch : trunk-12569-2.diff tested.

## Jabber.conf :

[general]
debug=yes                               ;;Turn on debugging by default.
autoprune=no                            ;;Auto remove users from buddy list.
autoregister=no                 ;;Auto register users from buddy list.

[compteJabber]                          ;;label
type=client                             ;;Client or Component connection
serverhost=10.128.16.10
username=serveurtable9@10.128.16.10      ;;Username with optional roster.
secret=toto
statusmessage="Serveur Asterisk"       ;;Have custom status message for
status=available

## extensions.conf :
...
exten => 599,1,Answer
exten => 599,2,JabberSend(compteJabber,empathy@10.128.16.10,Entrez le
numéro à composer)
exten => 599,3,JabberReceive(NUMERO)
exten => 599,4,JabberSend(compteJabber,empathy@10.128.16.10,${NUMERO})
exten => 599,5,HangUp

## gtalk.conf : leaved to default
                           
## Launching asterisk (trunk from today) :

JABBER: compteJabber INCOMING: <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="10.128.16.10" id="c6966ec4" xml:lang="en" version="1.0"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/></stream:features>

JABBER: compteJabber OUTGOING: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

JABBER: compteJabber INCOMING: <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>

JABBER: compteJabber OUTGOING: <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='10.128.16.10' version='1.0'>

JABBER: compteJabber INCOMING: <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="10.128.16.10" id="c6966ec4" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/></stream:features>

JABBER: compteJabber OUTGOING: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>AHNlcnZldXJ0YWJsZTkAdG90bw==</auth>

JABBER: compteJabber INCOMING: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>

JABBER: compteJabber OUTGOING: <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='10.128.16.10' version='1.0'>

JABBER: compteJabber INCOMING: <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="10.128.16.10" id="c6966ec4" xml:lang="en" version="1.0"><stream:features><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>

JABBER: compteJabber OUTGOING: <iq type='set' id='aaaaa'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><resource>asterisk</resource></bind></iq>

JABBER: compteJabber OUTGOING: <iq type='set' id='auth'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>

JABBER: compteJabber INCOMING: <iq type="result" id="aaaaa" to="10.128.16.10/c6966ec4"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>serveurtable9@10.128.16.10/asterisk</jid></bind></iq>

JABBER: compteJabber OUTGOING: <presence from='serveurtable9@10.128.16.10/asterisk'><status>"Serveur Asterisk"</status><priority>0</priority><c node='http://www.asterisk.org/xmpp/client/caps' ver='asterisk-xmpp' ext='voice-v1' xmlns='http://jabber.org/protocol/caps'/></presence>

JABBER: compteJabber OUTGOING: <iq type='get' id='roster'><query xmlns='jabber:iq:roster'/></iq>

JABBER: compteJabber INCOMING: <iq type="result" id="auth" to="serveurtable9@10.128.16.10/asterisk"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq>
Erreur de segmentation
By: phsultan (phsultan) 2008-05-15 03:32:56

PH : the segfault does not seem to be related to the patch. Does it happen too if you run an unpatched SVN trunk Asterisk? Did you actually place a call to exten 599?

Also, I was not able to reproduce it neither with my local XMPP server nor with Google.

Thanks for your feedback!
By: ph (ph) 2008-05-15 05:54:08

Philippe,
I've retested today. The segfault really seems to come from patch.
With no patch applied -> No segfault
With patch applied -> Segfault
The segfault occurs without dial the 599 extensions.
It appears when only jabber.conf modified ...

Thanks
By: phsultan (phsultan) 2008-05-15 08:26:30

It might be related to the way we handle message stanzas then. Can you provide a backtrace by issuing the following commands?

gdb asterisk
run -Tvvvvdddc
[wait for Asterisk to crash]
bt
bt full

Also, you mentioned that you had your jabber.conf file modified. What did you change?

Thanks Philippe!


By: Mahmoud (eech55) 2008-05-15 16:30:40

Hello phsultan, my apologies for the delay.

The patch seems working fine till now, and there was no segfault with me.

Setting the JID manually works, however I wanted to allow receiving messages from all JIDs as long as they are buddies, here's a related part of my extensions.conf. jabber.conf and gtalk.conf remain unchanged.

[gtalk-in]
exten => s,1,answer()
exten => s,n,SendText("What extention to call?")
exten => s,n,JabberReceive(${CALLERID(name)},RCV_EXT)
exten => s,n,goto(family,${RCV_EXT},1)
exten => s,n,hangup()

In the following output, I'm using the above configuration in extensions.conf. Asterisk answers the GTalk call as supposed, however, when I sent "000" to be dialed it wasn't successful. It works fine when I manually type in the GTalk account name (I'm trying to allow any GTalk account as long as he's a buddy, to have a similar effect as the 1st patch):-

ABBER: asterisk INCOMING:
<message to="asteriskJID@gmail.com/asterisk8299F195" type="chat" id="522" from="enduserJID@gmail.com/Talk.v1042486D9A3"><body>000</body><active xmlns="http://jabber.org/protocol/chatstates"/><nos:x value="disabled" xmlns:nos="google:nosave"/><arc:record otr="false" xmlns:arc="http://jabber.org/protocol/archive"/></message>
[May 16 01:11:35] NOTICE[28684]: res_jabber.c:1521 aji_handle_message: chan->appl : JabberReceive
[May 16 01:11:35] NOTICE[28684]: res_jabber.c:1522 aji_handle_message: chan->data : enduserJID@gmail.com/Talk.v1042486D9A3,RCV_EXT
[May 16 01:11:35] NOTICE[28684]: res_jabber.c:1539 aji_handle_message: chan was FOUND
 == Spawn extension (gtalk-in, s, 4) exited non-zero on 'Gtalk/mahmoud.khonji-d07c'

JABBER: asterisk OUTGOING: <iq type='set' from='asteriskJID@gmail.com/asterisk8299F195' to='enduserJID@gmail.com/Talk.v1042486D9A3' id='aaabc'><session type='terminate' id='3328567944' initiator='enduserJID@gmail.com/Talk.v1042486D9A3' xmlns='http://www.google.com/session'/></iq>
HQ*CLI>
JABBER: asterisk INCOMING: <iq to="asteriskJID@gmail.com/asterisk8299F195" id="aaabc" type="result" from="enduserJID@gmail.com/Talk.v1042486D9A3"/>

By they, how would you like me to test JabberReceive with SIP/IAX?


By: phsultan (phsultan) 2008-05-16 05:14:23

PH : I tried to address the segfault problem in the new patch, please test. Also, in this new version, JabberReceive takes two arguments, first one being the Jabber ID we're expecting a message from.

I'll add a timeout argument too, because it is currently stuck to 10s.

eech55 : new patch should make your dialplan example work now.

Note on SendText : SendText can be used instead of JabberSend if the channel is of type Gtalk. We could also imagine a use case outside of Gtalk like :
[sip-context]
exten => s,1,answer()
exten => s,n,JabberSend(asterisk,philippe.sultan@gmail.com,${CALLERID(name)} is trying to call ${EXTEN}, allow?)
exten => s,n,JabberReceive(philippe.sultan@gmail.com,RCV_EXT)
... string comparison, etc. ...

The considered context can be SIP/IAX or whatever protocol related, the Jabber* applications are used by the administrator to interact with Asterisk.

Guys, thank you very much for your help, we're close to having a new valuable Asterisk application ;)
By: Mahmoud (eech55) 2008-05-16 07:28:02

> [sip-context]
> exten => s,1,answer()
> exten => s,n,JabberSend(asterisk,philippe.sultan@gmail.com,${CALLERID(name)} is > trying to call ${EXTEN}, allow?)
> exten => s,n,JabberReceive(philippe.sultan@gmail.com,RCV_EXT)
> ... string comparison, etc. ...
Looks interesting. Will try it later on.

Just applied the trunk-12569-3.diff patch. All went as expected, and I was able to use the ${CALLERID(name)} variable.

Regarding JabberReceive application. In addition to the extra timeout argument, I think it would be great if we have a timeout action as well. To provide a professional end user experience, by sending him a friendly message instead of the immediate call termination.

Since a timeout message could be more than merely sending text messages, I think it would be more scalable (to adapt future applications as well) to jump to another step. Similar to the Dial application timeout, which moves to 101+ step, where a timeout action is specified (e.g. s,102,playback(tt-allbusy)

Personally, I think hard coding an offset (e.g. +101) may not be very scalable, just in case the context grows or complicates. I think having a default value, while allowing the choice of manually setting a step number via a forth JabberReceive argument would be the safest choice. For example:

[gtalk-in]
exten => s,1,answer()
exten => s,n,SendText("What extention would you like to call?")
exten => s,n,JabberReceive(${CALLERID(name)},RCV_EXT,10,105)
exten => s,n,SendText("Please wait, calling ${RCV_EXT}..")
exten => s,n,goto(family,${RCV_EXT},1)
exten => s,n,hangup()
exten => s,105,SendText("We are sorry. Too late response. Bye.")
exten => s,n,hangup()

In the above example, timeout is set to 10, and timeout action step is set to 105.

One more thing that seems irrelevent to the patches. I found an Asterisk crash condition, that exists without the patches as well, including the latest chan_gtalk.c and res_jabber.c SVNs.

Asterisk crashes when a GTalk user calls Asterisk's JID and immediately ends the call prior to Asterisk answering the call. I repeated this multiple times, and Asterisk crashed every time the GTalk user repeated that condition.

Here's the CLI output: http://sial.org/pbot/31055?tx=on&submit=Format+it%21


By: phsultan (phsultan) 2008-05-24 11:47:45

Gents, here's an updated patch. Older patches would produce a compile error since  recent modifications were committed to trunk (SVN rev 117802).

Thank you PH for having notified me about this problem.
By: Mahmoud (eech55) 2008-05-26 20:25:15

Hello phsultan. My appologies for the delay.

Tested with revision 118298. Hunks worked smoothly, no compile errors, and Asterisk does not crash when a Gtalk user calls and immediately ends it (as it previously did). The patch and application you made seem pretty reliable and predictable.

So far JabberReceive application is amazing for implementing GTalk chat conversations with end users. However, as far as extensions are concerned, there might be a better way for receiving extensions or menu selections (let's call it DTMF).

I think it would be better to integrate DTMF with dialplan similar to other channels. Doing so would result in simpler extensions.conf file, backward compatibility with previous parts of the extensions.conf, and applications such as "background" would work as expected.

Here, the "background" application keeps playing even though the user has sent some text (supposedly carrying DTMF):

[gtalk-in]
exten => s,1,answer()
exten => s,n,background(press_1_for_foo_or_2_for_bar)
exten => s,n,JabberReceive(foo@gmail.com,SELECTION)
exten => 1,1,....etc
exten => 2,1,....etc
exten => 3,1,....etc

The user would have to hear the complete voice message, and any request prior to that would not be stored in ${SELECTION} variable. Also, previously made voice menus would need to be modified in order to adapt GTalk requests.

I can think of two ways to solve this:

1) Asterisk to consider any input text as DTMF if it is lead by a special character such as +111 to dial 111 (as in FreeSWITCH)
2) Asterisk to consider any input text as DTMF, except when JabberReceive step is reached

I personally find method 2 easier from an end user's prespective. I know, it's GTalks fault for not including a DTMF pad. However they seem have no plans for including one anytime soon.


By: Ronald Chan (loloski) 2008-06-04 00:52:10

phsultan,

 I'd like to ask for a favor if you could also post a backport version of this for 1.4?

Thanks
By: Digium Subversion (svnbot) 2008-06-10 09:22:53

Repository: asterisk
Revision: 121552

A   team/phsultan/jabberreceive/

------------------------------------------------------------------------
r121552 | phsultan | 2008-06-10 09:22:50 -0500 (Tue, 10 Jun 2008) | 4 lines

Initiating new branch to work on JabberReceive. Follows up what's
being done in bug ASTERISK-11957


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=121552
By: phsultan (phsultan) 2008-06-10 10:30:23

A new branch is now available to test the JabberReceive application : http://svn.digium.com/view/asterisk/team/phsultan/jabberreceive/

Code snippets are now included in doc/jabber.txt

In this new version, timeout value can be set, so the new format becomes :
*CLI> core show application JabberReceive

 -= Info about application 'JabberReceive' =-

[Synopsis]
JabberReceive(Variable)

[Description]
JabberReceive(JID,Variable[,timeout])
 JID      - Jabber ID of the buddy to receive message from
 Variable - Variable to store message in
 timeout  - Defaults to 20s

*CLI>

Ronald (loloski) : this new feature won't be backported to 1.4, but I'll send a patch.

Mahmoud (eech55) : I think JabberReceive should be used in conjunction with functions/applications like SendText or JabberSend, not Background. The idea is really to set up a *text* channel within a call context. I understand your point but I'd really like to keep this application as simple as possible, from both usability and implementation perspectives. And this implies preventing overlapping with DTMF.

Gents, please give your feedback, and thanks again for all your efforts in testing and designing this application.
By: antonioams (antonioams) 2008-06-25 16:13:19

Hello,

I checked out the jabberreceive branch, but when i will compile it, it generates the following error:
=============================================================================
  [CC] res_jabber.c -> res_jabber.o
res_jabber.c: Na função ‘aji_start_tls’:
res_jabber.c:526: erro: ‘struct aji_client’ has no member named ‘stream_flags’
res_jabber.c:526: erro: ‘TRY_SECURE’ undeclared (first use in this function)
res_jabber.c:526: erro: (Each undeclared identifier is reported only once
res_jabber.c:526: erro: for each function it appears in.)
res_jabber.c: Na função ‘aji_tls_handshake’:
res_jabber.c:548: aviso: implicit declaration of function ‘SSL_library_init’
res_jabber.c:549: aviso: implicit declaration of function ‘SSL_load_error_strings’
=============================================================================

Could anybody help me to solve it?

thank you very much
By: phsultan (phsultan) 2008-06-27 08:05:43

antonioams, installing OpenSSL on your system should make the code compile again. Thanks!
By: antonioams (antonioams) 2008-06-27 09:41:11

Hi phsultan,

Thank you very much, it worked fine!
By: Andrea Sannucci (asannucci) 2008-09-18 17:56:33

Hi,
I'm using the Jabberreceive application to permit people create a account on my asterisk server by calling my asterisk gtalk account from the gtalk client.

This is the code (maybe not very clean, but work)

[google-in]
exten => s,1,answer()
exten => s,n,SendText("# Menu para configurar tu extension #")
exten => s,n,Set(COUNT=${DB(EXTENSION/PROG)})
exten => s,n,NoOp(${COUNT})
exten => s,n(no),SendText(your extension number will be: ${COUNT})
exten => s,n,SendText(choose a password for your Extension)
exten => s,n,JabberReceive(${CALLERID(name)},RCV_PW,40)
exten => s,n,SendText(Escribe tu nombre y apellido)
exten => s,n,JabberReceive(${CALLERID(name)},RCV_NOME,45)
exten => s,n,SendText(Escribe tu cuenta de correo electronico)
exten => s,n,JabberReceive(${CALLERID(name)},RCV_MAIL,60)
exten => s,n,SendText(## REVISA TUS DATOS ##)
exten => s,n,SendText(##                  ##)
exten => s,n,SendText(1. Numero Extension: ${COUNT})
exten => s,n,SendText(2. Clave:            ${RCV_PW})
exten => s,n,SendText(3. Nombre y Apellido:${RCV_NOME})
exten => s,n,SendText(4. Cuenta de Correo: ${RCV_MAIL})
exten => s,n,SendText(_______________________________)
exten => s,n,SendText(Los datos son correctos? (si/no))
exten => s,n,JabberReceive(${CALLERID(name)},RCV_SINO,30)
exten => s,n,GotoIf($[${RCV_SINO} = si]?si:no)
exten => s,n(si),NoOp(${RCV_MAIL},${RCV_PW},${RCV_NOME})
exten => s,n,System(echo [${COUNT}]"(templ)" >> /etc/asterisk/sip.conf)
exten => s,n,System(echo accountcode=${COUNT} >> /etc/asterisk/sip.conf)
exten => s,n,System(echo dial=SIP/${COUNT} >> /etc/asterisk/sip.conf)
exten => s,n,System(echo callerid=${RCV_NOME} >> /etc/asterisk/sip.conf)
exten => s,n,System(echo mailbox=${COUNT}@default >> /etc/asterisk/sip.conf)
exten => s,n,System(echo secret=${RCV_PW} >> /etc/asterisk/sip.conf)
exten => s,n,System(/etc/init.d/asterisk reload)
exten => s,n,SendText(Tu extension ha sido configurada)
exten => s,n,SendText(Ahora puedes configurar tu cliente SIP")
exten => s,n,SendText(Usa come nombre de Dominio(Registrar): sip.voztovoice.net)
exten => s,n,SendText(Puerto: 5060)
exten => s,n,SendText(Para probar el audio llama la extension numero 600)
exten => s,n,SendText(Chao)
exten => s,n,Set(COUNT=$[${COUNT} + 1])
exten => s,n,Set(DB(EXTENSION/PROG)=${COUNT})
exten => s,n,NoOp(${COUNT})
exten => s,n,Wait(1)
exten => s,n,hangup()
By: phsultan (phsultan) 2008-09-28 16:12:57

asannucci : that's a great use case, thanks a lot for reporting back!
By: Leif Madsen (lmadsen) 2008-11-20 16:13:56.000-0600

antonioams: did the code work for you?

asannucci: looks like the code worked for you since you provided a dialplan example (that should go into the documentation somewhere for when this gets committed).

phsultan: does this mean we should move this to reviewboard and get it reviewed? Once that is done we can SHIP IT! :)
By: Andrea Sannucci (asannucci) 2008-11-20 16:29:16.000-0600

@blitzrage: maybe i don't understood the question...
The code that i have post, creates one extension in sip.conf, using template.

My sip.conf look like:

[templ](!)
language=es
type=friend
record_out=Adhoc
record_in=Adhoc
qualify=yes
port=5060
host=dynamic

and each extension create trough gtalk jabberreceive application

[1001](templ)
accountcode=1001
dial=SIP/1001
callerid=XXX <1001>
mailbox=1001@default
secret=XXXX

All extensions using "local" context in my dialplan. This context only permit calls between extensions

@phsultan Do you know when the jabberreceive application will be included in the normal asterisk distribution?

Thank's
By: Leif Madsen (lmadsen) 2008-11-21 12:13:34.000-0600

@asannucci:  I meant thanks for the example you posted in http://bugs.digium.com/view.php?id=12569#92684

My main question was just to confirm that this code is working for you fine.
By: phsultan (phsultan) 2008-11-21 16:24:35.000-0600

Leif, you're right, I'll ask for a code review on the reviewboard soon.

I attached the doc/jabber.txt file. Can you guys give my your advice on it?

Thanks!
By: Andrea Sannucci (asannucci) 2008-11-23 17:29:42.000-0600

@blitzrage the code work fine on my asterisk.
If you want, you can try it from here: http://www.voztovoice.org/?q=node/5 (spanish)
Bye
By: John Covert (jcovert) 2008-11-28 11:46:13.000-0600

To make this even more useful:

Would it be possible to have a "textcontext" declared in jabber.conf, such that an incoming text message creates a very short call in the declared context; the expected code would need to do a JabberReceive (which would, of course, always complete immediately) and then do whatever other processing is appropriate.

It could send another text back, issue another JabberReceive, and carry on a dialogue without an audio call ever being established.  As long as the dialplan code does not exit, further text messages FROM THE SAME BUDDY/Resource would continue to be queued for that "call", if the call exits without clearing all the incoming text messages, a new call would be started as soon as the current one exits.

If a real call from the same buddy/resource were to come in, JabberReceive would return a special status, and the call would now behave as with the existing incoming call code and could be answered.  If a call comes in it would ring until answered, but if no Jabberreceive is executed before the current text "call" exits, a new call at the normal call context would be started.

Please consider this.  Thank you.

/john
By: phsultan (phsultan) 2008-12-11 12:38:06.000-0600

John,

XMPP chats (with JabberSend/JabberReceive) are indeed triggered by *voice* calls going though the dialplan. And if I understand correctly, you want to be able to start a dialog with Asterisk over XMPP from your XMPP client without involving Jingle nor GoogleTalk.

Instead of achieving that with XMPP messages, which should be reserved for pure text exchange, I think we could implement ad-hoc commands in Asterisk (http://xmpp.org/extensions/xep-0050.html), which would allow us to place calls using Local channels (e.g. no voice) and therefore reach all of the dialplan applications, including JabberSend and JabberReceive.

ad-hoc commands are implemented in most XMPP clients.

What do you think?

Philippe


By: John Covert (jcovert) 2008-12-11 12:47:57.000-0600

Hi Philippe,

Although when I wrote the note above, I was working on Gtalk and watching the Jabber messages if the Gtalk client sent a message before starting a call.  So I was thinking only in terms of a Gtalk client doing this, as part of a dialogue that might eventually lead to a voice call (maybe only a voice response from an application, such as a database service), generalizing it to not requiring that the client not necessarily be one that could initiate voice seems reasonable.

/john
By: phsultan (phsultan) 2008-12-11 13:04:39.000-0600

Well, if you use GoogleTalk, you can start a voice call from your client, have Asterisk answer it, and then call your JabberSend/JabberReceive statements.

asanucci gave an example of how to configure SIP accounts on his Asterisk server. A voice call is established between the GoogleTalk accounts and Asterisk, but no voice is actually exchanged, only XMPP messages, see : http://bugs.digium.com/view.php?id=12569#92684
By: Leif Madsen (lmadsen) 2008-12-11 14:41:37.000-0600

I'm just going to ask a question for fun here :)

I marked this as Ready For Review because I thought all the development was essentially done here, but are you planning on adding more stuff here? If so, maybe I'll just change this back to Ready For Testing.

Or, does it make sense to review as is for now, and then open a new issue for additional features here?

Please advise. Thanks!
By: John Todd (jtodd) 2008-12-11 15:26:03.000-0600

My question is this: does this application understand the concept of multiple XMPP instances registered to multiple XMPP servers?  There does not seem to be the ability to specify what XMPP account is being used to receive inbound messages.  The only thing specified is the user from which messages are received.

This is not a problem now, but imagine if someone clever decides to modify this code and create a regular expression capability.  It quickly becomes impossible to tell what is the destination of the XMPP messages, so I can't tell if people were sending a command to "sales@foo.com" or "support@foo.com" if both accounts are valid and listening in jabber.conf for this server.  I could come up with quite a few examples of how this would be useful, but I'll save the space here and let everyone envision it themselves over a cup of coffee.

I would strongly suggest that the command includes and uses the name of the Jabber stanza so that separate instances can be comprehended by the dialplan administrator.  This will (hopefully) prevent backwards-compatibility problems in the future when it is determined that really, this was a useful feature.  :-)

Ideally, it WOULD look like this:

*CLI> core show application JabberReceive

 -= Info about application 'JabberReceive' =-

[Synopsis]
JabberReceive(Variable)

[Description]
JabberReceive(account,JID,Variable[,timeout])
 account - the local named account to listen on (specified in jabber.conf)
 JID - Jabber ID of the buddy to receive message from
 Variable - Variable to store message in
 timeout - Defaults to 20s

*CLI>
By: phsultan (phsultan) 2008-12-12 04:34:52.000-0600

blitzrage: I indeed don't plan to add more features here, the ad-hoc commands feature should definitely be treated in a separate feature request. So you're right in saying most of the development has been done, even though jtodd's suggestion needs to be included.

Russell and Jeff Gehlbach posted reviews on the review board that need to be considered as well.

jtodd: What do you think of making the 'account' parameter optional, so that when a message comes in, this parameter is checked (only if set) against the 'to' attribute of the message?
By: John Todd (jtodd) 2008-12-12 08:59:38.000-0600

phsultan: Optional is certainly acceptable, but it seems more like this should be required.  However, I'll leave that to your discretion and I'll be happy as long as it's in there.  :-)
By: phsultan (phsultan) 2008-12-24 10:37:11.000-0600

Gents, the code has been modified quite a lot. Can you please check the updated branch?

The main modification are :
- the XMPP account configured in jabber.conf is now mandatory ;
- JABBER_RECEIVE is now a dialplan function that returns the content of the received XMPP message instead a dialplan application that stores it in a parameter.

Basically, instead of :
JabberReceive(bob@jabber.org,OPTION,20);
You'll use :
Set(OPTION=${JABBER_RECEIVE(asterisk-xmpp,bob@jabber.org,20)});
By: Leif Madsen (lmadsen) 2008-12-24 10:58:04.000-0600

Just gonna change this back to Ready For Testing since there were a bunch of changes recently, so maybe we can get a few more tests before we switch this back to Ready For Review.

BTW: I think the change from the application to a dialplan function was a great change. Thanks!
By: John Covert (jcovert) 2009-01-09 13:23:49.000-0600

I'm replying to Note 0096227 above, "you can start a voice call from your client, have Asterisk answer it, and then call your JabberSend/JabberReceive statements."

Not always.  If you don't have a Windows machine, you're stuck with only text messages.  For example, from this Mac, I was able to send a text message, which shows up as

<body>ahoy</body>

because I have jabber debug on.  I wish I could do something with that, rather than have the person at the other end thinking they're being ignored (which they are).

/john
By: phsultan (phsultan) 2009-01-09 13:56:31.000-0600

Well, GoogleTalk (which is the client refered to in this note), is not available on Mac. Only the Gmail plugin allows you to place voice calls to Asterisk, and we're currently working on making Asterisk work with it : http://bugs.digium.com/view.php?id=13971

I think we should first confirm that voice calls work between Asterisk and Gmail before moving forward. Could you please give your feedback on that?
By: John Covert (jcovert) 2009-01-09 14:24:07.000-0600

I'd love to, but...

From: http://mail.google.com/videochat

Unfortunately Gmail voice and video chat is not available for PowerPC Macs.
By: Max A Glucksmann (maxgo) 2009-01-10 10:18:21.000-0600

Hello, I'm very interested in using the new jabber channel as you have modified it... I understand that in a few words, is capable of:

1) Sending to the current gtalk client without specifying the destination or origin addresses in the jabber channel.

2) Receive also in the dialplan by specifying the client's gtalk address found within the ${CALLERID(name)} variable and the target variable.




<--------------------------->


If you could point out the stable version at this point and if there's a patch for 1.4 please let us know.


<--------------------------->




I'm trying to build a skype-like dialer, here's an example of the code:
[google]
exten => s,1,answer()
exten => s,2,JabberSend(${CALLERID(name)},Enter Destination Number)
exten => s,3,JabberReceive(${CALLERID(name)},DEST,30)
exten => s,4,JabberSend(${CALLERID(name)},Dialing ${DEST})
exten => s,5,Dial(Local/${DEST}@publicdialplanobd)

All the call rating and limitation is done after in the context " publicdialplan".

Thanks
By: Leif Madsen (lmadsen) 2009-01-10 11:22:07.000-0600

maxgo, please see the "Additional Information" at the top for the location of the code, and read through the comments for instructions on on how to configure.

phsultan, I will try and find some time next week to test this! Do I just need the Gtalk client in Windows? I can run WinXP in my VMware Fusion and do some testing there I think.
By: Max A Glucksmann (maxgo) 2009-01-10 16:57:01.000-0600

Hello blitzrage, phsultan...

I have tested successfully the version asterisk-jabberreceive-phsultan-trunk and have managed to build a dialer; first prompting the user to enter the destination number, then by doing a GTalk Account mapping, something like an ANI-mapping:

[google]
exten => s,1,answer()
exten => s,2,JabberSend(asterisk,${CALLERID(name)},Enter Destination Number)
exten => s,3,Set(DEST=${JABBER_RECEIVE(asterisk,${CALLERID(name)},20)})
exten => s,4,JabberSend(asterisk,${CALLERID(name)},Dialing ${DEST})
exten => s,5,Dial(Local/${DEST}@publicdialplanobd)

The thing is that many other things that were working perfectly in asterisk-1.4.22, now don't work:
- I have problems storing mysql cdrs.
- The debug in logger doesn't work.
- The SIP registration is failing in many cases...

Could you instruct us on how to implement the current functionality of jabber in asterisk-jabberreceive-phsultan-trunk into 1.4.22?

A patch would be highly appreciated, I read above from other user that he'd like to keep using 1.4 also.

Thank you very much and regards
By: Max A Glucksmann (maxgo) 2009-01-10 23:56:11.000-0600

Last observation, just for the record...

Apparently mysql_cdr was failing to insert records because some fields were not being filled by the gtalk channel, like:
CALLERID(number)
CDR(accountcode)

The default in the wiki for the creation of the table is NOT NULL for all fields.

It took me a while to figure it out because in this trunk version the logger is not showing debug, is this normal?

Besides that, it seems to me that the registration is less friendly for NAT devices than in 1.4. Could this have to do with something I read in this release's README about handling 4xx messages?

This is actually something important for ITSPs who serve customers using broadband service that only offers one public IP and forces them to use NAT.

If the REGISTRATION and DEBUG problems could be solved, the actual 1.6 and trunk are great.

Thanks
By: Michiel van Baak (mvanbaak) 2009-01-11 04:25:07.000-0600

maxgo,

What's the content of your logger.conf ?
If you dont specify debug there you wont see the output.

try this in there:
console => notice,warning,error,debug
By: Leif Madsen (lmadsen) 2009-01-11 10:36:28.000-0600

In addition, the registration and such problems would need to be separate bug reports. Before you do that though, I've seen separate bug reports for that already open, so please search for an open issue that addresses your concerns.

This bug report should only be concerned with the jabber related issues. Other issues are not part of this bug report. It could also be that it simply is a configuration issue as some things have changed in 1.6 in regards to SIP. I don't know without more information.

In regards to a backport of this to 1.4, it would be up to the original author (or someone else) to do that, but this will never go back into 1.4, and it may be that this application is using portions of 1.6 that do not exist in 1.4, so may not be trivial to backport.
By: Max A Glucksmann (maxgo) 2009-01-12 00:10:54.000-0600

I understand,

Thankfully, we have at least 2 servers. We'll be using:
- One for GTalk with:
   * phsultan-jabberreceive-trunk version
   * asterisk-addons-1.6.1-rc2 (solved the mysql_cdr problem)
     userfield or uniqueid, I don't know since I can't see debug
-  The other with 1.4.22 for REGISTRATIONs.

My logger.conf in phsultan-jabberreceive-trunk which doesn't show the green debug messages (neither in 1.6.x.x):

[logfiles]
;
; Format is "filename" and then "levels" of debugging to be included:
;    debug
;    notice
;    warning
;    error
;    verbose
;
; Special filename "console" represents the system console
;
;debug => debug
;console => error
;console => warning,error
;console => notice,warning,error
console => notice,warning,error,debug
;messages => notice,warning,error
;full => notice,warning,error,debug,verbose
;syslog keyword : This special keyword logs to syslog facility  
;syslog.local0 => notice,warning,error
;

Well, hope you can get again one Asterisk version that works for everything
:)
By: phsultan (phsultan) 2009-01-14 09:11:27.000-0600

blitzrage: you don't even need to have a GoogleTalk client to test the JABBER_RECEIVE function, a regular XMPP client without any media capability can be used. Here is a dialplan example, that allows the user bob@jabber.org to interact with Asterisk when a call comes to extension 1234 :

context from-ext {
 1234 => {
   Answer();
   JabberSend(asterisk-xmpp,bob@jabber.org,Call from $CALLERID(num) - choose an option to process the call);
   JabberSend(asterisk-xmpp,bob@jabber.org,1 : forward to cellphone);
   JabberSend(asterisk-xmpp,bob@jabber.org,2 : forward to work phone);
   JabberSend(asterisk-xmpp,bob@jabber.org,Default action : forward to your voicemail);
   Set(OPTION=${JABBER_RECEIVE(asterisk-xmpp,bob@jabber.org,20)});
   switch (${OPTION}) {
     case 1:
       JabberSend(asterisk-xmpp,bob@jabber.org,(Calling cellphone...);
       Dial(SIP/987654321);
       break;
     case 2:
       JabberSend(asterisk-xmpp,bob@jabber.org,(Calling workphone...);
       Dial(SIP/${EXTEN});
       break;
     default:
       Voicemail(${EXTEN}|u)
   }
 }
}

If you have a media capable XMPP client (ex. GoogleTalk), you can use the CALLERID(name) variable content along with the SendText/JABBER_RECEIVE application/function to chat with the end user. In the following example, a user establishes a voice call from his GoogleTalk client to Asterisk, and Asterisk asks him to enter an extension number that it will furtherly call :
context gtalk-in {
 s => {
   NoOp(Caller id : ${CALLERID(all)});
   Answer();
   SendText(Please enter the number you wish to call);
   Set(NEWEXTEN=${JABBER_RECEIVE(asterisk-xmpp,${CALLERID(name)})});
   SendText(Calling ${NEWEXTEN} ...);
   Dial(SIP/${NEWEXTEN);
   Hangup();
 }
}


By: phsultan (phsultan) 2009-01-14 09:25:58.000-0600

maxgo: Thank you very much for your feedback!

the problem in patching this code to 1.4 is that 1.6 (and SVN trunk) uses OpenSSL, and 1.4 uses GnuTLS to secure the XMPP traffic. This makes the corresponding code branches quite different now.


By: Max A Glucksmann (maxgo) 2009-01-30 00:12:10.000-0600

phsultan: My pleasure, the jabberreceive version works great, but I found a couple of details:


1) When I submit a sip reload, I keep getting this message, which repeats until Asterisk crashes:

- Failed to extend from 4 to 56

- Additionally, the OPTIONS messages keep getting sent to the realtime sipusers...

- I'm using the sipusers realtime table provided in the contrib folder as it comes.


2) When I use the VoiceMailMain application, there are some functions that make the sound messages to get scrambled and overlapped (switch folders, delete messages, undelete messages).


I'm running Asterisk jabberreceive within a LAN with the VoIP phone I'm using to hear the voicemail messages, and by seeing "top" in Linux when the messages get scrambled, I see that CPU as well as Memory have plenty left of resources (CPU uses only about 3% of a 2.4 GHz P4, and there are still about 256MB of RAM free).


I've tested all the other apps I used with 1.2 and 1.4 (MySQL CDR, Realtime Dialplan, Realtime sipusers, Realtime iaxusers, AGI, Background) and everything is working great; only those 2 issues appear.


The * box is working as gateway of the LAN also so our LAN phones get proxied outbound and inbound, but I tested with phones in the WAN obtaining the same results. Registrations are working well also, no problem with NAT in this type of config in neither side of the network.


Well, I'll appreciate very much if you could test on your side these apps to see if you can reproduce them. I get always the same results.


Best Regards


By: Max A Glucksmann (maxgo) 2009-01-30 00:30:40.000-0600

[root@comtel-networks ~]# asterisk -cgvvvr
Asterisk SVN-phsultan-jabberreceive-r168313-/trunk, Copyright (C) 1999 - 2008 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
 == Parsing '/etc/asterisk/asterisk.conf':   == Found
 == Parsing '/etc/asterisk/extconfig.conf':   == Found
 == Binding iaxusers to mysql/comtelpbx/iaxusers
 == Binding sippeers to mysql/comtelpbx/sipusers
 == Binding sipusers to mysql/comtelpbx/sipusers
 == Binding voicemail to mysql/comtelpbx/voicemail
 == Binding publicdialplan to mysql/comtelpbx/publicdialplan
 == Binding inboundtrunk to mysql/comtelpbx/inboundtrunk
 == Binding google to mysql/comtelpbx/google
 == Binding outboundtrunk to mysql/comtelpbx/outboundtrunk
 == Binding macros to mysql/comtelpbx/macros
Connected to Asterisk SVN-phsultan-jabberreceive-r168313-/trunk currently running on comtel-networks (pid = 4632)
Verbosity is at least 3
comtel-networks*CLI>
By: Max A Glucksmann (maxgo) 2009-01-30 00:33:55.000-0600

Message example before crashing (hundreds of messages appear with only about 10 sip users):

failed to extend from 4 to 57
Reliably Transmitting (NAT) to 201.152.x.x:5064:
OPTIONS sip:1021014@201.152.x.x:49162 SIP/2.0
Via: SIP/2.0/UDP 24.127.x.x:5060;branch=z9hG4bK3da82225;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@24.127.x.x>;tag=as4c0ac6c0
To: <sip:1021014@201.152.x.x:49162>
Contact: <sip:asterisk@24.127.x.x>
Call-ID: 3ace572d107961d038c70810532b3ed1@24.127.x.x
CSeq: 102 OPTIONS
User-Agent: ComtelPBX
Date: Fri, 30 Jan 2009 02:42:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Length: 0
By: Max A Glucksmann (maxgo) 2009-01-30 00:38:02.000-0600

On the other hand, top output exactly when voicemail messages are getting scrambled:

[root@comtel-networks ~]# top -d 3

top - 00:39:23 up  2:51,  4 users,  load average: 0.27, 0.40, 0.41
Tasks: 157 total,   4 running, 152 sleeping,   0 stopped,   1 zombie
Cpu(s):  1.3%us,  2.0%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.3%hi,  1.7%si,  0.0%st
Mem:   1026392k total,   604088k used,   422304k free,    47628k buffers
Swap:   524280k total,        0k used,   524280k free,   175372k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                      
4632 root      15   0 38972  16m 8344 S  3.0  1.7   1:31.15 asterisk                                                                    
3942 root      15   0 16896 9828 2816 S  0.7  1.0   0:11.73 comtelpbx-ratin                                                              
3557 root      15   0  379m  64m  25m R  0.3  6.5   0:20.22 firefox-bin
By: Max A Glucksmann (maxgo) 2009-02-10 12:24:00.000-0600

Hello phsultan, blitzrage...

I've been using this release since we're very interested in using gtalk as a dialer, and we need to receive the messages entered by the user, such as number to be dialed...

There are a couple of things working wrong that are very important:

1) SIP Reload makes Asterisk send hundreds of OPTION messages until it crashes:

201.208.63.117   (None)      417994226f71366  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      35a48dce7ee68a4  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      6dc8175c5824f63  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      7e6958d220b37ab  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      2dacecfc62547d5  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      075faf6858878bf  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      27748a1b7e4c4e6  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      49171bb341b9208  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      7633ff9f1e00c50  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      0596bcf468fbdef  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      669796ac4eb92e1  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      510179ce231d933  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      47c4e4f80137a21  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      0226df8c1d2a53c  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      694bad0c673452e  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      62e24d2716cd718  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      7970be6c4d0b4a7  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      050f625a7ee1124  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      535f1b8f70d7a8c  0x0 (nothing)    No       Init: OPTIONS
201.208.63.117   (None)      495e08827dd5af5  0x0 (nothing)    No       Init: OPTIONS


failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 54
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 54
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56
failed to extend from 4 to 56

2) VoiceMailMain overlaps sound files when reproducing in certain sections, like changing folders, deleting, etc...

We'd love your advice in order to fix this version; we really appreciate the efforts you've done with the jabber channel and look forward for a version having full functionality with it.

Thanks and Regards,

Max
By: John Todd (jtodd) 2009-02-16 16:37:12.000-0600

Failed for me, though I'm not on Linux.  I've included a full bt and various configuration bits in the file I attached - jabber-broken1.txt

As soon as the JabberReceive function was called, I got a core dump.  There wasn't even a message sent to the JabberReceive function - it died without provocation.
By: phsultan (phsultan) 2009-02-17 04:14:13.000-0600

John, I just updated the code to try to fix your issue. Can you try again?
By: John Todd (jtodd) 2009-02-17 14:37:50.000-0600

OK, that worked fine for short messages.  Excellent!  Now, on to the next bug.  :-)


If I send a big block of text at the system, it chokes and shows nothing.  I cut and pasted a big section of Jabberwocky into my chat client and sent it to the waiting Asterisk system.  It didn't show anything:

*CLI>
*CLI> [Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:4573 do_setnat: Setting NAT on RTP to Off
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:6739 sip_alloc: Allocating new SIP dialog for 00059bf1-a0de004c-13adddad-0b756fc6@10.10.3.7 - INVITE (With RTP)
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:4573 do_setnat: Setting NAT on RTP to Off
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:3745 __sip_ack: Stopping retransmission on '00059bf1-a0de004c-13adddad-0b756fc6@10.10.3.7' of Response 101: Match Found
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:4573 do_setnat: Setting NAT on RTP to Off
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:7807 process_sdp: Got unsupported a:fmtp:18 annexb=no in SDP offer
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:7807 process_sdp: Got unsupported a:fmtp:101 0-15 in SDP offer
[Feb 17 20:34:55] DEBUG[5622]: chan_sip.c:18924 handle_request_invite: Checking SIP call limits for device 2203
[Feb 17 20:34:55] DEBUG[5622]: pbx.c:3635 pbx_extension_helper: Launching 'JabberSend'
   -- Executing [995@to-binfone:1] JabberSend("SIP/2203-7e79d8c0", "jtphone,jtodd@jabber.loligo.com,"Rah rah sis boom bah!"") in new stack

JABBER: jtphone OUTGOING: <message type='chat' to='jtodd@jabber.loligo.com' from='jtphone@jabber.loligo.com/asterisk'><body>"Rah rah sis boom bah!"</body></message>
[Feb 17 20:34:55] DEBUG[5622]: devicestate.c:652 handle_devstate_change: Processing device state change for 'SIP/2203'
[Feb 17 20:34:55] DEBUG[5622]: devicestate.c:602 process_collection: Adding per-server state of 'Not in use' for 'SIP/2203'
[Feb 17 20:34:55] DEBUG[5622]: devicestate.c:608 process_collection: Aggregate devstate result is 1
[Feb 17 20:34:55] DEBUG[5622]: devicestate.c:624 process_collection: Aggregate state for device 'SIP/2203' has not changed from 'Not in use'

JABBER: jtphone INCOMING: <message type="chat" id="purple7ace65a" to="jtphone@jabber.loligo.com/asterisk" from="jtodd@jabber.loligo.com/Adium"><x xmlns="jabber:x:event"><composing/></x><body>`Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe:
All mimsy were the borogoves,
  And the mome raths outgrabe.



"Beware the Jabberwock, my son!
  The jaws that bite, the claws that catch!
Beware the Jubjub bird, and shun
  The frumious Bandersnatch!"
He took his vorpal sword in hand:
  Long time the manxome foe he sought --
So rested he by the Tumtum tree,
  And stood awhile in thought.
And, as in uffish thought he stood,
  The Jabberwock, with eyes of flame,
Came whiffling through the tulgey wood,
  And burbled as it came!
One, two! One, two! And through and through
  The vorpal blade went snicker-snack!
He left it dead, and with its head
  He went galumphing back.
"And, has thou slain the Jabberwock?
  Come to my arms, my beamish boy!
O frabjous day! Callooh! Callay!'
  He chortled in his joy.


`Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe;
All mimsy were the borogoves,
  And the mome raths outgrabe.

</body><html xmlns="http://jabber.org/protocol/xhtml-im"><body xmlns="http://www.w3.org/1999/xhtml">`Twas brillig, and the slithy toves<br/>  Did gyre and gimble in the wabe:<br/>All mimsy were the borogoves,<br/>  And the mome raths outgrabe.<br/><br/><br/><br/>"Beware the Jabberwock, my son!<br/>  The jaws that bite, the claws that catch!<br/>Beware the Jubjub bird, and shun<br/>  The frumious Bandersnatch!"<br/>He took his vorpal sword in hand:<br/>  Long time the manxome foe he sought --<br/>So rested he by the Tumtum tree,<br/>  And stood awhile in thought.<br/>And, as in uffish thought he stood,<br/>  The Jabberwock, with eyes of flame,<br/>Came whiffling through the tulgey wood,<br/>  And burbled as it came!<br/>One, two! One, two! And through and through<br/>  The vorpal blade went snicker-snack!<br/>He left it dead, and with its head<br/>  He went galumphing back.<br/>"And, has thou slain the Jabberwock?<br/>  Come to my arms, my beamish boy!<br/>O frabjous day! Callooh! Callay!'<br/>  He chortled in his joy.<br/><br/><br/>`Twas brillig, and the slithy toves<br/>  Did gyre and gimble in the wabe;<br/>All mimsy were the borogoves,<br/>  And the mome raths outgrabe.<br/><br/></body></html></message>
[Feb 17 20:34:57] WARNING[5622]: res_jabber.c:1086 aji_recv: XML parsing failed

*CLI>
*CLI> [Feb 17 20:35:05] NOTICE[5622]: res_jabber.c:780 acf_jabberreceive_read: Timed out : no message received from jtodd@jabber.loligo.com
[Feb 17 20:35:05] DEBUG[5622]: pbx.c:3635 pbx_extension_helper: Launching 'Set'
   -- Executing [995@to-binfone:2] Set("SIP/2203-7e79d8c0", "OPTION=") in new stack
[Feb 17 20:35:05] DEBUG[5622]: pbx.c:3635 pbx_extension_helper: Launching 'NoOp'
   -- Executing [995@to-binfone:3] NoOp("SIP/2203-7e79d8c0", ""Wowzers - we got "") in new stack
[Feb 17 20:35:05] DEBUG[5622]: pbx.c:3635 pbx_extension_helper: Launching 'Hangup'
   -- Executing [995@to-binfone:4] Hangup("SIP/2203-7e79d8c0", "") in new stack
[Feb 17 20:35:05] DEBUG[5622]: pbx.c:4228 __ast_pbx_run: Spawn extension (to-binfone,995,4) exited non-zero on 'SIP/2203-7e79d8c0'
 == Spawn extension (to-binfone, 995, 4) exited non-zero on 'SIP/2203-7e79d8c0'
[Feb 17 20:35:05] DEBUG[5622]: channel.c:1567 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/2203-7e79d8c0'
[Feb 17 20:35:05] DEBUG[5622]: channel.c:1662 ast_hangup: Hanging up channel 'SIP/2203-7e79d8c0'
[Feb 17 20:35:05] DEBUG[5622]: chan_sip.c:5571 sip_hangup: Hangup call SIP/2203-7e79d8c0, SIP callid 00059bf1-a0de004c-13adddad-0b756fc6@10.10.3.7
[Feb 17 20:35:05] DEBUG[5622]: chan_sip.c:5511 hangup_cause2sip: AST hangup cause 16 (no match found in SIP)
[Feb 17 20:35:05] DEBUG[5622]: devicestate.c:652 handle_devstate_change: Processing device state change for 'SIP/2203'
[Feb 17 20:35:05] DEBUG[5622]: devicestate.c:602 process_collection: Adding per-server state of 'Not in use' for 'SIP/2203'
[Feb 17 20:35:05] DEBUG[5622]: devicestate.c:608 process_collection: Aggregate devstate result is 1
[Feb 17 20:35:05] DEBUG[5622]: devicestate.c:624 process_collection: Aggregate state for device 'SIP/2203' has not changed from 'Not in use'
[Feb 17 20:35:05] DEBUG[5622]: chan_sip.c:3745 __sip_ack: Stopping retransmission on '00059bf1-a0de004c-13adddad-0b756fc6@10.10.3.7' of Response 102: Match Found

*CLI>
By: John Todd (jtodd) 2009-02-17 14:48:37.000-0600

Also: I recall a discussion about caching pre-responses for some period of time to account for slow Asterisk systems.  In other words, what happens if a user sends a command prior to ${JABBER_RECEIVE} being ready to accept it?  I think we should have some configurable cache that allows one or more messages to pre-date the ${JABBER_RECEIVE} command.   It could be configured in jabber.conf in [general], or perhaps a per-peer setup would be more flexible with a default in [general].  Something like "cache=3" which would save received messages for 3 seconds and ditch them if no ${JABBER_RECEIVE} requested/matched them in that time period.

This is important when this method starts to be used as an API-like tool between automated systems.  The reply may come back from the remote system with surprising speed, and it would be bad if it was lost because the dialplan was busy with some task that took a few seconds to do.

Asterisk -> User: "Send your command"
[Dialplan does other things for 10 seconds]
User -> Asterisk: "Hang up"
[Dialplan finally gets around to ${JABBER_RECEIVE}, but user has already sent command.  Now what?]
By: John Todd (jtodd) 2009-02-19 11:15:33.000-0600

FWIW: I suspect this is a problem with core and not with this module, but IAX2 calls lock up after a few minutes and then will not accept any further calls via IAX2.  Just figured it would be worth mentioning.

# asterisk -rvvvc
Asterisk SVN-phsultan-jabberreceive-r176523-/trunk, Copyright (C) 1999 - 2008 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
 == Parsing '/etc/asterisk/asterisk.conf':   == Found
 == Parsing '/etc/asterisk/extconfig.conf':   == Found
Connected to Asterisk SVN-phsultan-jabberreceive-r176523-/trunk currently running on core1 (pid = 27168)
Verbosity was 0 and is now 3
   -- Executing [6060@from-handset:2] Dial("SIP/2001-8b2980c0", "IAX2/blork6083/6060@from-users") in new stack
[Feb 19 17:12:12] WARNING[27168]: app_dial.c:1712 dial_exec_full: Unable to create channel of type 'IAX2' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing [6060@from-handset:3] Congestion("SIP/2001-8b2980c0", "") in new stack
 == Spawn extension (from-handset, 6060, 3) exited non-zero on 'SIP/2001-8b2980c0'
   -- Executing [h@from-handset:1] Hangup("SIP/2001-8b2980c0", "") in new stack
 == Spawn extension (from-handset, h, 1) exited non-zero on 'SIP/2001-8b2980c0'
core1*CLI>
By: Max A Glucksmann (maxgo) 2009-03-02 14:34:30.000-0600

Hello,

Is there any plan in the future to enable Asterisk with video/chat support through http://gmail.com/videochat/ web client?

When I call from gmail.com, Asterisk doesn't answer the calls...
By: Leif Madsen (lmadsen) 2009-03-02 15:59:19.000-0600

maxgo: that is not part of this branch. The only plans for supporting that would be via a community contribution, and I do not know of any community members currently working on that.
By: Max A Glucksmann (maxgo) 2009-03-02 16:25:45.000-0600

Cool, np...

I tested version 177340 and it has some issues REGISTERing... only registers the first entry in the sip.conf file, it shows it at last though:

Host dnsmgr Username Refresh State Reg.Time
xxx.xxx.xxx.xxx:5060 N 1646405xxxx 120 Unregistered
xxx.xxx.xxx.xxx:5060 N 1831359xxxx 120 Unregistered
xxx.xxx.xxx.xxx:5060 N 1877467xxxx 120 Unregistered
xxx.xxx.xxx.xxx:5060 N 1877446xxxx 120 Unregistered
xxx.xxx.xxx.xxx:5060 N 1877446xxxx 105 Registered Mon, 02 Mar 2009 17:15:18

176523 was working fine regarding this...

Additionally, 177340 doesn't show sip debug for outgoing registrations...
By: phsultan (phsultan) 2009-03-03 04:05:39.000-0600

jtodd: I suspect the copied text contains characters that prevented iksemel from parsing it properly. That's probably related to http://bugs.digium.com/view.php?id=14390

Also, the 'timeout' paramater in jabber.conf defines the value (in seconds) message stanzas are kept in Asterisk's internal stack before being pulled by JABBER_RECEIVE. This is indeed the result of a discussion we had before to address the possibility that messages get lost.
By: phsultan (phsultan) 2009-03-03 04:10:31.000-0600

maxgo: Since the Gtalk voice/video chat plugin has significant signaling differences with the Gtalk client, a new branch has been created to make Asterisk work with it, see http://bugs.digium.com/view.php?id=13971

At the moment, only voice calls work. Please test it, thanks!
By: Leif Madsen (lmadsen) 2009-04-06 21:41:53

I tested this branch tonight, and the function worked great for me! I think the branch might be a bit behind trunk right now though, and probably needs to be updated.

What else is this waiting on before we move it to 'Ready for Review' ?

Thanks! This is great functionality.
By: Leif Madsen (lmadsen) 2009-04-07 22:39:23

Both jtodd and myself have used this functionality successfully, so I'd like to get it reviewed on reviewboard, and potentially merged!  Great work!
By: John Todd (jtodd) 2009-04-09 20:45:05

Yes, I've tested quite a bit with no further apparent errors, but I haven't done a complete "regression" test yet.  I'd say "works fine for me!" as a recommendation, though.
By: phsultan (phsultan) 2009-04-10 08:17:23

Ok guys, thanks for your feedback. Let's try to merge this code with now.

Have a nice week end!
By: Russell Bryant (russell) 2009-04-10 09:17:34

Is the code on reviewboard the latest version of the diff?  If so, I'll try to review it soon.
By: Leif Madsen (lmadsen) 2009-05-20 07:57:17

Ping? Request for reporter to let us know if the code on reviewboard is the latest available so Russell can review it.
By: phsultan (phsultan) 2009-05-20 08:21:07

Russell and Tilghman reviewed the code and posted comments on the reviewboard. I still have to modify the existing code to include the fixes they proposed.
By: Leif Madsen (lmadsen) 2009-05-20 08:51:30

Setting to assigned while waiting for incorporated changes. Thanks!
By: Matt Riddell (zx81) 2009-05-20 16:45:24

What's the url for the reviewboard entry - or rather which entry number is it?
By: Leif Madsen (lmadsen) 2009-07-27 14:37:46

I really love this feature. Is there anything that can be done to push it along? :)
By: phsultan (phsultan) 2009-07-28 08:07:38

I expect to come back to fixing the code not before september. Moreover the various diffs cannot be read anymore on the reviewboard : https://reviewboard.asterisk.org/r/88/. Having them back would help a lot :)
By: Leif Madsen (lmadsen) 2009-07-28 09:25:38

Looks like the diff wasn't posted correctly to reviewboard. I'd suggest you use post-review. More information here:  http://www.asterisk.org/doxygen/trunk/Reviewboard.html

(per Russell)
By: Leif Madsen (lmadsen) 2009-09-08 13:50:07

Well, it's September now, so I think I'll bump this issue and see if phsultan has any ability to update the post on reviewboard and move this forward :) (sorry, I love this issue :))
By: phsultan (phsultan) 2009-09-09 11:42:07

Yep, I love it too ;)

I'll repost the diff by the end of the week and ask for a new review.
By: Leif Madsen (lmadsen) 2009-09-09 11:54:29

Awesome! That should get us moving forward again. I appreciate it!
By: phsultan (phsultan) 2009-09-14 13:37:34

The new diff I posted this week end is being reviewed, see : https://reviewboard.asterisk.org/r/88/
By: Digium Subversion (svnbot) 2009-09-25 05:57:05

Repository: asterisk
Revision: 220457

U   trunk/CHANGES
U   trunk/channels/chan_gtalk.c
U   trunk/channels/chan_jingle.c
U   trunk/configs/jabber.conf.sample
U   trunk/doc/jabber.txt
U   trunk/include/asterisk/jabber.h
U   trunk/res/res_jabber.c

------------------------------------------------------------------------
r220457 | phsultan | 2009-09-25 05:57:04 -0500 (Fri, 25 Sep 2009) | 13 lines

Add JABBER_RECEIVE as a dialplan function, implement SendText in Jingle channels

JABBER_RECEIVE (along with JabberSend) makes Asterisk interact with users over
XMPP to process calls.
SendText can be used instead of JabberSend in the context of XMPP based voice
channels (chan_gtalk and chan_jingle).

(closes issue ASTERISK-11957)
Reported by: eech55
Tested by: phsultan, asannucci, lmadsen, jtodd, maxgo

Review: https://reviewboard.asterisk.org/r/88/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=220457