sockets other than RTP ones.
The main change is a new API function in main/rtp.c (see there
for a description)
int ast_stun_request(int s, struct sockaddr_in *dst,
const char *username, struct sockaddr_in *answer)
which can be used to send an STUN request on a socket, and
optionally wait for a reply and store the STUN_MAPPED_ADDRESS
into the 'answer' argument (obviously, the version that
waits for a reply is blocking, but this is no different
from DNS resolutions).
Internally there are minor modifications to let stun_handle_packet()
be somewhat configurable on how to parse the body of responses.
At the moment i am not committing any change to the clients,
but adding STUN client support is extremely simple, e.g. chan_sip.c
could do something like this:
+ add a variable to store the stun server address;
static struct sockaddr_in stunaddr = { 0, }; /*!< stun server address */
+ add code to parse a config file of the form "stunaddr=my.stun.server.org:3478"
(not shown for brevity);
+ right after binding the main sip socket, talk to the stun server to
determine the externally visible address
if (stunaddr.sin_addr.s_addr != 0)
ast_stun_request(sipsock, &stunaddr, NULL, &externip);
so now 'externip' is set with the externally visible address.
so it is really trivial.
Similarly ast_stun_request could be called when creating the RTP
socket (possibly adding a struct sockaddr_in field in the struct
ast_rtp to store the externalip).
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@75034 f38db490-d61c-443f-a65b-d21fe96a405b
+ mark a potentially dangerous write-past-end-of-buffer
+ localize some variables in the block generating stun replies.
As before, not ready yet for a merge to 1.4
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@74850 f38db490-d61c-443f-a65b-d21fe96a405b
ast_rtp_new_with_bindaddr():
1. add comments to the logic of the main loop;
2. use a common exit point on failure so the cleanup is done only in one place;
3. handle failures in rtp_socket() in the main loop of the function;
No functional changes except for #3 above, so it is not yet
worthwhile merging this and other changes to 1.4
Once the cleanup work on this file will be complete (which among
other things should include some extensions to the stun support)
it might be a good thing to push all the changes to 1.4
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@74813 f38db490-d61c-443f-a65b-d21fe96a405b
(which is very little, at the moment).
Eventually, when the functionality is extended, the changes can be merged
back to 1.4. At the moment this is pointless.
Note, this change is whitespace only.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@74571 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r71063 | murf | 2007-06-22 08:10:24 -0600 (Fri, 22 Jun 2007) | 1 line
My conditions for merging amaflags info was naive; DOCUMENTATION is the default, although null is possible; theft of user-settable fields is not good. Just copy them, leave them alone.
This is for bug 10016. (plus a small fix to rtp, to elim a compiler warning (dev mode))
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@71093 f38db490-d61c-443f-a65b-d21fe96a405b
Also adds a new "reporting" permission for manager, since it can be incredibly spammy.
This permission was discussed on the -dev mailing list some months back.
Issue 8613, patch by johann8384, with some minor changes by me.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@70961 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r65842 | russell | 2007-05-24 09:49:05 -0500 (Thu, 24 May 2007) | 5 lines
Fix the calculation of the RTT for RTCP. The previous code would result in
oscillating and incorrect data. Additionally, the RTT would sometimes report
negative values due to incorrect calculations.
(issue #9601, patch from davetroy)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@65843 f38db490-d61c-443f-a65b-d21fe96a405b
file doc/qos.tex has been updated to document the new functionality.
(issue #9540, patch submitted by IgorG)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@62457 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r61707 | qwell | 2007-04-20 16:35:27 -0500 (Fri, 20 Apr 2007) | 8 lines
Avoid invalid seqno cycling detection.
Per comment from Dave Troy:
This adds back in some simple typecasting I had in an earlier version
which I realize now may be breaking things.
Issue #9554.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@61708 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r59358 | russell | 2007-03-29 12:17:41 -0500 (Thu, 29 Mar 2007) | 13 lines
Merged revisions 59357 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r59357 | russell | 2007-03-29 12:14:33 -0500 (Thu, 29 Mar 2007) | 5 lines
If an error occurs when reading from an RTP socket, and the error code does not
indicate that we should try again, then return NULL instead of a "null frame".
This will prevent Asterisk from trying over and over again, and eventually
causing the system to crash. (issue #8285, john)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@59359 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r59207 | russell | 2007-03-26 12:45:55 -0500 (Mon, 26 Mar 2007) | 7 lines
The AUDIORTPQOS and VIDEORTPQOS variables are not fully functional in some
because they get set in sip_hangup. So, there are common situations where
the variables will not be available in the dialplan at all. So, this patch
provides an alternate method for getting to this information by introducing
AUDIORTPQOS and VIDEORTPQOS dialplan functions.
(issue #9370, patch by Corydon76, with some testing by blitzrage)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@59208 f38db490-d61c-443f-a65b-d21fe96a405b
T.140/RFC 2793 is a live communication channel, originally
created for IP based text phones for hearing impaired.
Feels very much like the old Unix talk application.
This code is developed and disclaimed by John Martin of Aupix, UK.
Tested for interoperability by myself and Omnitor in Sweden,
the company that wrote most of the specifications.
A big thank you to everyone involved in this.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@54838 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r53429 | russell | 2007-02-07 11:39:31 -0600 (Wed, 07 Feb 2007) | 7 lines
When parsing the NTP timestamp in a sender report message, you are supposed to
take the low 16 bits of the integer part, and the high 16 bits of the
fractional part. However, the code here was erroneously taking the low 16 bits
of the fractional part. It then shifted the result 16 bits down, so the result
was always zero. This fix makes it grab the appropriate high 16 bits, instead.
(issue #8991, pointed out by andre_abrantes)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@53431 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r53052 | file | 2007-01-31 18:24:20 -0600 (Wed, 31 Jan 2007) | 2 lines
When going on hold have the side that was put on hold reinvite back to Asterisk. When going off hold have the side that was taken off hold reinvited back to the other party.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@53053 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52645 | russell | 2007-01-29 15:26:27 -0600 (Mon, 29 Jan 2007) | 6 lines
Fix a problem with packet-to-packet bridging and DTMF mode translation. P2P
bridging can only be used when the DTMF modes don't match if the core is
monitoring DTMF in both directions. Then, the core will handle the translation.
Otherwise, this bridging method can not be used.
(issue #8936)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@52646 f38db490-d61c-443f-a65b-d21fe96a405b