https://origsvn.digium.com/svn/asterisk/trunk
................
r185363 | dbrooks | 2009-03-31 11:46:57 -0500 (Tue, 31 Mar 2009) | 44 lines
Merged revisions 185362 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185362 | dbrooks | 2009-03-31 11:37:12 -0500 (Tue, 31 Mar 2009) | 35 lines
Fix incorrect parsing in chan_gtalk when xmpp contains extra whitespaces
To drill into the xmpp to find the capabilities between channels, chan_gtalk
calls iks_child() and iks_next(). iks_child() and iks_next() are functions in
the iksemel xml parsing library that traverse xml nodes. The bug here is that
both iks_child() and iks_next() will return the next iks_struct node
*regardless* of type. chan_gtalk expects the next node to be of type IKS_TAG,
which in most cases, it is, but in this case (a call being made from the
Empathy IM client), there exists iks_struct nodes which are not IKS_TAG data
(they are extraneous whitespaces), and chan_gtalk doesn't handle that case,
so capabilities don't match, and a call cannot be made.
iks_first_tag() and iks_next_tag(), on the other hand, will not return the
very next iks_struct, but will check to see if the next iks_struct is of
type IKS_TAG. If it isn't, it will be skipped, and the next struct of type
IKS_TAG it finds will be returned. This assures that chan_gtalk will find
the iks_struct it is looking for.
This fix simply changes all calls to iks_child() and iks_next() to become
calls to iks_first_tag() and iks_next_tag(), which resolves the capability
matching.
The following is a payload listing from Empathy, which, due to the extraneous
whitespace, will not be parsed correctly by iksemel:
<iq from='dbrooksjab@235-22-24-10/Telepathy' to='astjab@235-22-24-10/asterisk' type='set' id='542757715704'> <session xmlns='http://www.google.com/session' initiator='dbrooksjab@235-22-24-10/Telepathy' type='initiate' id='1837267342'> <description xmlns='http://www.google.com/session/phone'> <payload-type clockrate='16000' name='speex' id='96'/>
<payload-type clockrate='8000' name='PCMA' id='8'/>
<payload-type clockrate='8000' name='PCMU' id='0'/>
<payload-type clockrate='90000' name='MPA' id='97'/>
<payload-type clockrate='16000' name='SIREN' id='98'/>
<payload-type clockrate='8000' name='telephone-event' id='99'/>
</description>
</session>
</iq>
Review: http://reviewboard.digium.com/r/181/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@185426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r119741 | phsultan | 2008-06-02 16:35:24 +0200 (Mon, 02 Jun 2008) | 13 lines
Do not link the guest account with any configured XMPP client (in
jabber.conf). The actual connection is made when a call comes in
Asterisk.
Apply this fix to Jingle too.
Fix the ast_aji_get_client function that was not able to retrieve an
XMPP client from its JID.
(closes issue #12085)
Reported by: junky
Tested by: phsultan
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@119743 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r118020 | phsultan | 2008-05-23 12:33:21 +0200 (Fri, 23 May 2008) | 15 lines
- remove whitespaces between tags in received XML packets before giving
them to the parser ;
- report Gtalk error messages from a buddy to the console.
This patch makes Asterisk "Google Jingle" (chan_gtalk) implementation
work with Empathy. Note that this is only true for audio streams, not
video.
Thank you to PH for his great help!
(closes issue #12647)
Reported by: PH
Patches:
trunk-12647-1.diff uploaded by phsultan (license 73)
Tested by: phsultan, PH
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@118021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r97489 | phsultan | 2008-01-09 17:44:24 +0100 (Wed, 09 Jan 2008) | 7 lines
Set the caller id within the gtalk_alloc function.
As underlined in issue #10437 by Josh, we need to prevent a possible
memory leak. We only set the name part of the caller id, the number
part is not relevant when dealing with JIDs.
Closes issue #11549.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove the AST_FORMAT_MAX_* types, as these are consuming 3 out of our available 32 bits.
- Add a native slin16 type, so that 16kHz codecs can translate without losing resolution.
(This doesn't affect anything immediately, until another codec has wb support.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r80661 | phsultan | 2007-08-24 13:42:46 +0200 (Fri, 24 Aug 2007) | 9 lines
Closes issue #10509
Googletalk calls are answered too early, which results in CDRs wrongly
stating that a call was ANSWERED when the calling party cancelled a
call before before being established.
We must not answer the call upon reception of a 'transport-accept' iq
packet, but this packet still needs to be acknowledged, otherwise the
remote peer would close the call (like in #8970).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@80662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79174 | file | 2007-08-13 11:18:04 -0300 (Mon, 13 Aug 2007) | 4 lines
(closes issue #10437)
Reported by: haklin
Don't set the callerid name and number a second time on a newly created channel. ast_channel_alloc itself already sets it and setting it twice would cause a memory leak.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r72125 | qwell | 2007-06-27 12:10:32 -0500 (Wed, 27 Jun 2007) | 4 lines
Don't modify a variable that we don't want modified. Make a copy of it instead.
Issue 10029, patch by phsultan with slight modifications by me (to remove needless casts).
Note: chan_jingle in trunk does not appear to have the same bug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@72134 65c4cc65-6c06-0410-ace0-fbb531ad65f3
