[Home]

Summary:ASTERISK-09125: [patch] DTMF Is not relayed chan_sip[others]<->chan_gtalk <- ... -> chan_gtalk <-> chan_sip[others]
Reporter:Gregory Hinton Nietsky (irroot)Labels:
Date Opened:2007-03-28 03:33:17Date Closed:2007-09-14 07:43:52
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_gtalk
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_gtalk.dtmf.patch1
( 1) gtalk_dtmf_rtp.patch1
Description:The way DTMF is originated in chan_gtalk is not the way chan_gtalk expects it.

i have started using chan_gtalk as a interbranch routing the problem is when DTMF is sent the transmision by chan_gtalk is not read by chan_gtalk.

this is a prelimanary patch that reads the message in the way it is sent.

this seems to be inline with http://www.xmpp.org/extensions/xep-0181.html

also included is the beginings of a patch to recive text messages and parse them for DTMF/Text to be sent to the client from the google talk client.
Comments:By: Serge Vecher (serge-v) 2007-03-28 08:36:10

does the patch you've posted fix (or attempt to fix) the issue, or is it just new functionality? If latter, please post it in another issue marked "feature."

Also, we need to see what's going on, with debug for sip/gtalk turned on.
By: Gregory Hinton Nietsky (irroot) 2007-03-29 01:45:52

it appears to fix the problem DTMF sent from chan_gtalk CANNOT curently be passed on by a reciving chan_gtalk.

this patch detects the incoming (outofband) dtmf and passes it on.

this is a BUG FIX.
By: Matt Riddell (zx81) 2007-03-29 02:22:46

Could you post or fax a disclaimer so that the patch can be looked at.
By: Serge Vecher (serge-v) 2007-03-29 08:41:30

see bottom of http://bugs.digium.com/main_page.php and let us know when you fax it in. Thanks for contributing!
By: Gregory Hinton Nietsky (irroot) 2007-03-29 09:57:19

its a pleasure ...

ill send it shortly when cheaper to do so.

im also working on a overhaul of the RTP in chan_gtalk it is pretty messy at the moment and seems that only G711 is supported properly.ill be adding GSM/G726/G729 to the existing speex/iLBC/G711/G723 support although not supported by the google talk client there is no reason not to include them for other clients/*.
By: Gregory Hinton Nietsky (irroot) 2007-03-29 14:03:09

disclaimer has been faxed ...
By: Matt Riddell (zx81) 2007-03-29 18:56:42

+ if (message) {
+ ast_log(LOG_ERROR,"GOOGLE! Message Received: %s\n", message);

Does this need to be an error?

Couldn't it be debug or verbose?
By: Gregory Hinton Nietsky (irroot) 2007-03-30 02:31:11

Certainaly needs to be dealt with properly and error does not make much sense.

here is what i have in mind

1)IM arives when no call is active send back a message letting the sender know this is a voip link or prehaps hook it into a CLI that a user may interact with the system.or prehaps this can be hooked into the MWI via ODBC when a phone subscribes for MWI the messages are sent this is quite trivial for SIP.

2)when on a call parse the IM for DTMF/Text and send it to the bridge appropriately.
By: phsultan (phsultan) 2007-03-30 16:34:57

Hi irroot,

I won't help regarding the possible DTMF bug here, I'll just bring a comment on the text message handling feature part of your report.

> 1)IM arives when no call is active send back a message letting the sender know this is a voip link or prehaps hook it into a CLI that a user may interact with the system.or prehaps this can be hooked into the MWI via ODBC when a phone subscribes for MWI the messages are sent this is quite trivial for SIP.

> 2)when on a call parse the IM for DTMF/Text and send it to the bridge appropriately.

IM coming to Asterisk are first processed by res_jabber, not chan_gtalk. It's better to handle those messages there, for example by hooking a text receiver function just as it is done here : http://bugs.digium.com/view.php?id=8659

irroot, would you mind having a look at bug ASTERISK-8421 and give your feedback? It looks like we plan to achieve similar goals here :)
By: Gregory Hinton Nietsky (irroot) 2007-03-31 11:02:42

in a effort to rescue my karma .... i submit the lattest chan_gtalk patch

1)dtmf outofband transmision works between chan_gtalk (at least)
2)the codecs are now chosen and set based on payload exchange
3)you can now dial Dial(Gtalk/<account>/<user>/<exten>...)
the above will add a asterisk tag to the initiate request contianing the attributes cid_num cid_name and exten these will be set on the remote (chan_gtalk only) as required so the dialed party will see the calling partys details.
4)cid setting has been redone to take the above into account using the concept from http://bugs.digium.com/view.php?id=8536

the codec selection process is as follows
incoming call
-------------
compare recived codecs to configured codecs find the prefered codec and set the nativeformat and reply with all jointly capable codecs.
should data arive that is not the native codec but a capable codec change to the recived form

outgoing call
-------------
choose and set the best available codec and send all capable codecs to the remote.
when a accept arrives check our codec with the list recived and adjust to a new codec if the prefered codec is not acceptable to remote (not in accept reply)

have fun ...
By: Gregory Hinton Nietsky (irroot) 2007-03-31 11:13:46

just loaded the rtp patch required for setting the payload type of ilbc (as used by google talk clients)

this is reported as
http://bugs.digium.com/view.php?id=9426
By: Serge Vecher (serge-v) 2007-04-02 08:59:41

irroot: rescuing karma is a noble attempt; let me see if I can help you out here. First, let's stick with fixing the original bug here. Keep the patches to related issues that you are working on in those issues. If some of the patches cross into other poster's bugs, see if you can collaborate with the poster.
By: Gregory Hinton Nietsky (irroot) 2007-04-03 04:08:21

thx serge i reported the RTP problem above split it off as a seperate bug as it is related to the RTP core.the only overlap there may exist is in the callerid as i propose sending the callerid with the initiate request to be seen by other * servers as with our interbranch routing it is more a alternate solution im proposing.

the callerid/exten proposal i have implemented does not seem to curently fit into the XMPP specification im hoping to add it to this channel for *<->* and make a case for it latter on and as it is not 100% up to spec it should be a configrable option.

im sticking to 2 issues.

1)RTP support for more than just G711U and proper support for the google clients native codec iLBC the payload type is 102 not 97 and this makes it practicaly impossible to work with *.on this note i have tested and succeeded with iLBC/GSM/G729 between 2 * servers as well as Google iLBC (102).
2)DTMF support from * to * is working and in place the proposal for useing the IM function is a nice want to have and there are other patches surfacing i will be looking at.

should i split this into a RTP and DTMF or carry on looking at it as a single development strand ??

all the best and hope this is of value to someone i know it is working fantastic for us allowing interbranch routing without the need for dynamic DNS or central IAX/SIP server is a big plus.
By: Joshua C. Colp (jcolp) 2007-09-06 13:23:24

Can you give a final yes or no on this phsultan?
By: phsultan (phsultan) 2007-09-07 11:10:15

We definitely need to fix this the way it's done in the first patch, without the 'message' iq handing part which is out of the scope of the experienced bug.

Before committing this, I'd like to know if we really need to check the 'duration' value when sending DTMF (BEGIN or END).

Also, the Jingle DTMF spec has been modified since the patch submission. We should change the 'action' attribute value from 'content-info' to 'session-info' so that we keep an implementation close to the standard draft (still in experimental status) : http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0181.xml?r1=590&r2=984
By: Digium Subversion (svnbot) 2007-09-13 06:28:36

Repository: asterisk
Revision: 82309

------------------------------------------------------------------------
r82309 | phsultan | 2007-09-13 06:28:35 -0500 (Thu, 13 Sep 2007) | 4 lines

Closes issue ASTERISK-9125, reported and patched by irrot, with slight
modifications by me.

Handle DTMF sent by Asterisk properly.
------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-09-13 06:36:17

Repository: asterisk
Revision: 82310

------------------------------------------------------------------------
r82310 | phsultan | 2007-09-13 06:36:17 -0500 (Thu, 13 Sep 2007) | 12 lines

Merged revisions 82309 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r82309 | phsultan | 2007-09-13 13:47:14 +0200 (Thu, 13 Sep 2007) | 4 lines

Closes issue ASTERISK-9125, reported and patched by irrot, with slight
modifications by me.

Handle DTMF sent by Asterisk properly.
........

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-09-14 07:43:52

Repository: asterisk
Revision: 82373

------------------------------------------------------------------------
r82373 | phsultan | 2007-09-14 07:43:51 -0500 (Fri, 14 Sep 2007) | 1 line

Fix DTMF following what has been done in issue ASTERISK-9125. Thanks irroot.
------------------------------------------------------------------------