[Home]

Summary:ASTERISK-08421: [patch] Add a jabber text receiver application, and make Asterisk a Gtalk to phone gateway
Reporter:phsultan (phsultan)Labels:
Date Opened:2006-12-22 07:41:59.000-0600Date Closed:2007-08-27 11:00:19
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_jabber
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_jabberauthorize.c
( 1) app_jabberauthorize-2.c
( 2) branch-1.4-aji_recv-1.diff
( 3) trunk-aji_recv-1.diff
( 4) trunk-aji_recv-2.diff
( 5) trunk-aji_recv-3.diff
Description:Hi Matthew and other people working on jabber,

I'd like to submit two features to your acceptance, that make Asterisk a jabber gateway to dial extensions from a jabber user client. Here is the implemented behaviour (tested with GoogleTalk clients and a SIP gateway) :
- make a Gtalk call to Asterisk (needs a GoogleTalk account)
- Asterisk answers and plays a file
- Asterisk sends a text message asking the user for a number to dial
- Asterisk dials the number and makes the remote GoogleTalk client talk with the corresponding POTS phone (through a SIP gateway in our case)

Two applications are used to achieve this :
- JabberReceive Dial plan application
 * waits for incoming jabber text messages, and stores received text in a channel variable

JabberReceive relies on aji_handle_message to find a running Gtalk channel that matches with the received jid (uid part), and pass a text frame that contains the body of the jabber message to the channel on success. On the channel side, the received text frame is stored in a channel variable (defined in the dialplan).
JabberReceive needs to find a caller ID, so that this feature depends on bug ASTERISK-8301 (new patch will be provided to allow SIP extensions dialing).

- JabberAuthorize Dial plan application
 * sends a text message to the jid that started a Gtalk channel with Asterisk in order to welcome and authorize a user to dial extensions through Asterisk

JabberAuthorize relies on Asterisk's jabber client's buddy list to achieve access control. In the future, we might prompt the user either through a chat or form window (if the remote jabber client supports it) to provide credentials for example.

Notes :
- you can also have Asterisk registered as a component rather than a user, in this case, you'll need to fix Asterisk as per bug ASTERISK-8177.
- also tested this with a jingle enabled client (jabbin), this needs some hacking though.

JabberReceive is attached in trunk-aji_recv-1.diff (as it is closed to JabberSend, I included it in res_jabber).
JabberAuthorize is attached in app_jabberauthorize.c

Enjoy the ending year celebration, and merry christmas!

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

Sample configuration files :
extensions.ael :
---------------
context default {
       s => {
         Answer();
         Wait(2);
         Playback(greetings-message);
         JabberAuthorize(asterisk);
         JabberReceive(asterisk,NEW);
         Dial(SIP/${NEW}@10.0.0.2);
}

jabber.conf :
-------------
[asterisk]
type=client
serverhost=talk.google.com
username=philippe.sultan@gmail.com/asterisk
secret=*******
port=5222
usetls=yes

sip.conf :
----------
; SIP peer needs to have canreinvite=no, as native bridging is not yet
; implemented in chan_gtalk
[10.0.0.2]
type=peer
context=from-sip-gateways
host=10.0.0.2
nat=no
canreinvite=no
Comments:By: phsultan (phsultan) 2006-12-22 08:36:23.000-0600

Forgot to mention : disclaimer was sent a while ago
By: phsultan (phsultan) 2007-01-02 05:23:17.000-0600

Added JabberReceive for branch 1.4, mostly the same patch as for trunk.

JabberAuthorize can be compiled as is for branch 1.4.

Note : SIP extensions dialing won't work without the caller id fix from ASTERISK-8301, I'll send an update for branch 1.4.

Happy New Year!
By: phsultan (phsultan) 2007-02-21 04:36:11.000-0600

Patch updated to latest revision (conflicts detected).
By: phsultan (phsultan) 2007-03-28 05:19:08

Patch updated to latest revision (conflicts detected).
By: Serge Vecher (serge-v) 2007-03-28 08:42:46

welcome back Phillip
By: phsultan (phsultan) 2007-03-29 05:43:33

;)
By: Gregory Hinton Nietsky (irroot) 2007-03-31 05:59:51

thx for pointing me here looks  good ...

the proposal i have for chan_gtalk is to recive messages while on a call is to parse them for DTMF and allow Gtalk users to send DTMF into the bridge.

i like the idea of this patch but the following concerns.

1)when there is a up channel ignore the message and let it be handled by gtalk send it to the client or process it as dtmf
2)prehaps look at a hook in the MWI and pass the messages to the client when supported SIP with a MESSAGE packet.
3)also maybe looking at res_odbc to hold the messages,this way they can be accesed via a web client prehaps.
By: philipp2 (philipp2) 2007-05-06 10:08:04

Cool stuff. Applied this patch as well as 8536 to Asterisk 1.4.4. branch-1.4-aji_recv-1.diff had two failed HUNKS that needed manual attention.

JabberAuthorize("Gtalk/remoteuser-558e", "asterisk") in new stack
[May  6 16:52:33] WARNING[16306]: app_jabberauthorize.c:130 jabber_authorize_exec: Could not find buddy Gtalk in list.

JabberAuthorize apparently looks for "Gtalk" while it should be searching for "remoteuser" instead?

Remarks:
* The naming of "JabberReceive" is a bit misleading as that suggest to exactly complement "JabberSend"; however JabberSend does not require an established gtalk channel
* Related to that: It would be great if there was a way to receive Jabber text messages _without_ a gtalk channel (and then e.g. use SendText or sms or sipsak to relay the message)
* The synopsis auf JabberAuthorize is not clear and should be more specific as to what exactly this does (e.g. look for the existence of the caller in the buddy list of the given argument; also the descrption fails to mention that JabberAuthorize requires an argument
By: phsultan (phsultan) 2007-05-06 10:28:44

Thanks a lot for your productive remarks! I will address the issues you spotted as soon as possible, please stay tuned :)
By: phsultan (phsultan) 2007-05-07 11:54:42

Hi philipp2,

> Cool stuff. Applied this patch as well as 8536 to Asterisk 1.4.4. branch-1.4-aji_recv-1.diff had two failed HUNKS that needed manual attention.
>
> JabberAuthorize("Gtalk/remoteuser-558e", "asterisk") in new stack
> [May 6 16:52:33] WARNING[16306]: app_jabberauthorize.c:130 jabber_authorize_exec: Could not find buddy Gtalk in list.
>
> JabberAuthorize apparently looks for "Gtalk" while it should be searching for "remoteuser" instead?

It looks like the problem stays in the caller ID processing.

This work cannot be considered as a bug fix so it won't be merged into 1.4. Can you please use an SVN trunk revision of Asterisk instead (a patch is also available for trunk in 8536), and give your feedback again?

> Remarks:
> * The naming of "JabberReceive" is a bit misleading as that suggest to exactly complement "JabberSend"; however JabberSend does not require an established gtalk channel
> * Related to that: It would be great if there was a way to receive Jabber text messages _without_ a gtalk channel (and then e.g. use SendText or sms or sipsak to relay the message)

You're right, aji_send_exec contains an unused ast_channel parameter though. Maybe we can keep it this way for the moment, and modify it eventually?

> * The synopsis auf JabberAuthorize is not clear and should be more specific as to what exactly this does (e.g. look for the existence of the caller in the buddy list of the given argument; also the descrption fails to mention that JabberAuthorize requires an argument

OK, I'll attach a new version (app_jabberauthorize-2.c) in order to address that.

Thank you again!

Philippe
By: Olle Johansson (oej) 2007-05-14 08:03:43

Shouldn't jabberReceive be an addition to DISA for Gtalk channels? The application isn't that much different, really. And if we integrate it properly, it might be something that can be multiprotocol at some point.
By: phsultan (phsultan) 2007-08-27 10:59:45

Closing this feature request, lack of testing.