68 Commits (a08f48089c6df7169f59aa632b0e92dc978cd42a)

Author	SHA1	Message	Date
Kinsey Moore	fbed3175d8	Fix an issue where media would not flow for situations where the legacy STUN code is in use. ... The STUN packets should *not* be blocked by strict RTP. (closes issue ASTERISK-20415) Reported by: Michele Cicciotti patches: uploaded by Joshua Colp (trunk r369817) ........ Merged revisions 373702 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@373703 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	a2e582c835	Revert change to res_rtp_asterisk committed in r373236 (1.8) ... The change committed in r373236 attempted to account for endpoints that increased their RTP timestamp in DTMF end of event re-transmissions. This change attempted to make Asterisk continue to work with endpoints that failed to follow the RFC while maintaining the fix that allowed for out of order DTMF to be handled. Unfortunately, there is no free lunch, and this patch broke any system that sent DTMF immediately after an RTP session was established or when an SSRC is updated. As such, that patch is being reverted for the previous behavior. Endpoints that erroneously increase the RTP timestamp in DTMF end of event packets will not work properly with Asterisk. (issue ASTERISK-20424) ........ Merged revisions 373504 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@373505 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	a57f43ef4e	When processing RFC 2833 DTMF, accomodate increasing timestamps in End events ... While endpoints should not be changing the source timestamp between DTMF event packets, the fact is there exists those endpoints that do exactly that. To work around this, we absorb timestamps within the expected re-transmit period. Note that this period only affects End of Event packets, so it should not prevent the detection of new DTMF digits that happen to arrive right on top of each other. (closes issue ASTERISK-20424) Reported by: Vladimir Mikhelson Tested by: mjordan, Vladimir Mikhelson Review: https://reviewboard.asterisk.org/r/2124 ........ Merged revisions 373236 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@373237 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Michael L. Young	66b43b9e0d	Fix Incrementing Sequence Number For Retransmitted DTMF End Packets ... In Asterisk 1.4+, a fix was put in place to increment the sequence number for retransmitted DTMF end packets. With the introduction of the RTP engine API in 1.8, the sequence number was no longer being incremented. This patch fixes this regression as well as cleans up a few lines that were not doing anything. (closes issue ASTERISK-20295) Reported by: Nitesh Bansal Tested by: Michael L. Young Patches: 01_rtp_event_seq_num.patch uploaded by Nitesh Bansal (license 6418) asterisk-20295-dtmf-fix-cleanup.diff uploaded by Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/2083/ ........ Merged revisions 372185 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@372198 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	64f8ea213e	Handle extremely out of order RFC 2833 DTMF ... The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will, if a packet arrives out of order, drop the packet. This is to prevent duplicate ton generation in the Asterisk core. Since the RTP layer does not buffer data itself, this is the only option the RTP layer currently has for handling packets that arrive out of order. For the most part, this doesn't matter. For a particular digit, so long as a BEGIN packet arrives before the first END packet, the digit will be produced. If subsequent BEGIN packets arrive interleaved with the ENDs, they will be dropped; likewise, if the BEGIN or END packets themselves are out of order, those packets are dropped but sufficient information is conveyed to the Asterisk core to produce the appropriate digit. For certain sequences of DTMF packets - most notably when, for a particular digit, an END packet arrives before any BEGIN packet for that digit - this is a real problem. When an END arrives before any BEGINs, the END packet is dropped - but at the same time, it causes subsequent BEGIN packets for that digit to be ignored. When the next in order END packet arrives, it too is dropped - Asterisk believes that there was no initial BEGIN. The solution this patch provides is to trust the END packet to convey the information needed for the Asterisk core to produce the DTMF digit. If we receive an END packet, and it: * Has a timestamp greater then the last timestamp received from an END packet * Does not have the same sequence number as the last received sequence number (and is thus not an END packet retransmission) Then we send the END frame up to the Asterisk core. It contains enough DTMF information for Asterisk to produce the digit. On the other hand, if we receive a BEGIN or continuation packet that occurs with a timestamp equal to or less then the last END timestamp, then we've received something out of order - but we already have received enough information to produce the digit. These packets are dropped. Much thanks goes to Olle Johansson (oej) for providing the idea for this solution. Review: https://reviewboard.asterisk.org/r/2033/ (closes issue ASTERISK-18404) Reported by: Stephane Chazelas Tested by: Matt Jordan ........ Merged revisions 370252 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@370271 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	9dbc175305	Fix a variety of memory leaks ... This patch addresses a number of memory leaks in a variety of modules that were found by a static analysis tool. A brief summary of the changes: * app_minivm: free ast_str objects on off nominal paths * app_page: free the ast_dial object if the requested channel technology cannot be appended to the dialing structure * app_queue: if a penalty rule failed to match any existing rule list names, the created rule would not be inserted and its memory would be leaked * app_read: dispose of the created silence detector in the presence of off nominal circumstances * app_voicemail: dispose of an allocated unique ID field for MWI event un-subscribe requests in off nominal paths; dispose of configuration objects when using the secret.conf option * chan_dahdi: dispose of the allocated frame produced by ast_dsp_process * chan_iax2: properly unref peer in CLI command "iax2 unregister" * chan_sip: dispose of the allocated frame produced by sip_rtp_read's call of ast_dsp_process; free memory in parse unit tests * func_dialgroup: properly deref ao2 object grhead in nominal path of dialgroup_read * func_odbc: free resultset in off nominal paths of odbc_read * cli: free match_list in off nominal paths of CLI match completion * config: free comment_buffer/list_buffer when configuration file load is unchanged; free the same buffers any time they were created and config files were processed * data: free XML nodes in various places * enum: free context buffer in off nominal paths * features: free ast_call_feature in off nominal paths of applicationmap config processing * netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct that is allocated by the method. Failures in ast_sockaddr_resolve could result in the users of the method not knowing whether or not the buffer was allocated. The method will now not allocate the ast_sockaddr struct if it will return failure. * pbx: cleanup hash table traversals in off nominal paths; free ignore pattern buffer if it already exists for the specified context * xmldoc: cleanup various nodes when we no longer need them * main/editline: various cleanup of pointers not being freed before being assigned to other memory, cleanup along off nominal paths * menuselect/mxml: cleanup of value buffer for an attribute when that attribute did not specify a value * res_calendar*: responses are allocated via the various *_request method returns and should not be allocated in the various write_event methods; ensure attendee buffer is freed if no data exists in the parsed node; ensure that calendar objects are de-ref'd appropriately * res_jabber: free buffer in off nominal path * res_musiconhold: close the DIR* object in off nominal paths * res_rtp_asterisk: if we run out of ports, close the rtp socket object and free the rtp object * res_srtp: if we fail to create the session in libsrtp, destroy the temporary ast_srtp object (issue ASTERISK-19665) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1922 ........ Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@366881 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Mark Michelson	e751e565fc	Fix core FINDING 2, FINDING 3, and FINDING 4 from Coverity's CONSTANT_EXPRESSION_RESULT report. ... These three all are in RTP code that attempts to print the number of sequence number cycles in an RTCP RR report. The code was masking out the upper 16 bits and then shifting the number right by 16 bits. This led to an all zero result in all cases. The fix is to do the shift without the bit masking. (issue ASTERISK-19649) ........ Merged revisions 365298 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@365299 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	a3a5fee8a1	Fix places in resources where a negative return value could impact execution ... This patch addresses a number of modules in resources that did not handle the negative return value from function calls adequately. This includes: * res_agi.c: if the result of the read function is a negative number, indicating some failure, the result would instead be treated as the number of bytes read. This patch now treats negative results in the same manner as an end of file condition, with the exception that it also logs the error code indicated by the return. * res_musiconhold.c: if spawn_mp3 fails to assign a file descriptor to srcfd, and instead assigns a negative value, that file descriptor could later be passed to functions that require a valid file descriptor. If spawn_mp3 fails, we now immediately retry instead of continuing in the logic. * res_rtp_asterisk.c: if no codec can be matched between two RTP instances in a peer to peer bridge, we immediately return instead of attempting to use the codec payload type as an index to determine the appropriate negotiated codec. (issue ASTERISK-19655) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1863/ ........ Merged revisions 362362 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@362364 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	b60e54fd10	Correct output of RTCP jitter statistics in SR and RR reports ... Change the RTCP RR and SR generation code to convert Asterisk's internal jitter statistics to be represented in RTP timestamp units based on the rate of the codec in use instead of in seconds. (closes issue ASTERISK-14530) ........ Merged revisions 351611 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@351612 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Mark Michelson	e80559676f	Eliminate odd initialization of probation variable. ... ........ Merged revisions 351306 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@351308 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Jonathan Rose	58a5154a27	Adds pjmedia probation concepts to res_rtp_asterisk's learning mode. ... In order to better handle RTP sources with strictrtp enabled (which is now default in 10) using the learning mode to figure out new sources when they change is handled by checking for a number of consecutive (by sequence number) packets received to an rtp struct based on a new configurable value called 'probation'. Also, during learning mode instead of liberally accepting all packets received, we now reject packets until a clear source has been determined. Review: https://reviewboard.asterisk.org/r/1663/ ........ Merged revisions 351287 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@351289 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Stefan Schmidt	4b0486b824	Fix regression that 'rtp/rtcp set debup ip' only works when also a port was specified. ... (closes issue ASTERISK-18693) Reported by: Davide Dal Fra Review: https://reviewboard.asterisk.org/r/1600/ Reviewed by: Walter Doekes ........ Merged revisions 346292 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@346293 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Matthew Nicholson	248bf67ae5	only attempt to do stun handling on ipv4 or ipv4 mapped to ipv6 addresses ... Patch by: jkonieczny (modified) ASTERISK-18490 ........ Merged revisions 344330 from http://svn.asterisk.org/svn/asterisk/branches/1.8 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@344334 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Kinsey Moore	91a65d8b3f	Merged revisions 340970 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r340970 | kmoore | 2011-10-14 15:49:39 -0500 (Fri, 14 Oct 2011) | 8 lines Quiet RTCP Receiver Reports during fax transmission RTCP is now disabled for "inactive" RTP audio streams during SIP T.38 sessions. The ability to disable RTCP streams in res_rtp_asterisk was missing, so this code was added to support the bug fix. (closes issue ASTERISK-18400) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@340971 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Olle Johansson	42c967eea9	Change strictrtp option to default to yes in the RTP module ... Suggested by Kapejod on Facebook Review: https://reviewboard.asterisk.org/r/1448/ (closes issue ASTERISK-18587) Thanks for quick feedback to kpfleming and Tilghman --Denna och nedanstående rader kommer inte med i loggmeddelandet-- M CHANGES M configs/rtp.conf.sample M res/res_rtp_asterisk.c git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@337178 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Russell Bryant	5f1a062fa6	Merged revisions 336877 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r336877 | russell | 2011-09-19 19:56:20 -0500 (Mon, 19 Sep 2011) | 36 lines Fix crashes in ast_rtcp_write(). This patch addresses crashes related to RTCP handling. The backtraces just show a crash in ast_rtcp_write() where it appears that the RTP instance is no longer valid. There is a race condition with scheduled RTCP transmissions and the destruction of the RTP instance. This patch utilizes the fact that ast_rtp_instance is a reference counted object and ensures that it will not get destroyed while a reference is still around due to scheduled RTCP transmissions. RTCP transmissions are scheduled and executed from the chan_sip scheduler context. This scheduler context is processed in the SIP monitor thread. The destruction of an RTP instance occurs when the associated sip_pvt gets destroyed (which happens when the sip_pvt reference count reaches 0). However, the SIP monitor thread is not the only thread that can cause a sip_pvt to get destroyed. The sip_hangup function, executed from a channel thread, also decrements the reference count on a sip_pvt and could cause it to get destroyed. While this is being changed anyway, the patch also removes calling ast_sched_del() from within the RTCP scheduler callback. It's not helpful. Simply returning 0 prevents the callback from being rescheduled. (closes issue ASTERISK-18570) Related issues that look like they are the same problem: (issue ASTERISK-17560) (issue ASTERISK-15406) (issue ASTERISK-15257) (issue ASTERISK-13334) (issue ASTERISK-9977) (issue ASTERISK-9716) Review: https://reviewboard.asterisk.org/r/1444/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@336878 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Kinsey Moore	98c4fee4cb	Merged revisions 328823 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r328823 | kmoore | 2011-07-19 12:57:18 -0500 (Tue, 19 Jul 2011) | 11 lines RTP bridge away with inband DTMF and feature detection When deciding whether Asterisk was allowed to bridge the call away from the core, chan_sip did not take into account the usage of features on dialed channels that require monitoring of DTMF on channels utilizing inband DTMF. This would cause Asterisk to allow the call to be locally or remotely bridged, preventing access to the data required to detect activations of such features. (closes 17237) Review: https://reviewboard.asterisk.org/r/1302/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.10@328824 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Leif Madsen	7caa2349af	Merged revisions 328209 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines Introduce <support_level> tags in MODULEINFO. This change introduces MODULEINFO into many modules in Asterisk in order to show the community support level for those modules. This is used by changes committed to menuselect by Russell Bryant recently (r917 in menuselect). More information about the support level types and what they mean is available on the wiki at https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.10@328247 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
David Vossel	513c680b8c	Adds pass-through support for codec CELT. ... This patch adds pass-through support for CELT. CELT formats are defined in codecs.conf and can be configured to any sample rate a CELT endpoint supports. This patch also addresses a crash in channel.c resulting from a frame list being freed incorrectly. This crash was discovered while testing a CELT translator which had to split encoded audio into multiple frames. The codec translator is not a part of this patch, but may be contributed in the future. Review: https://reviewboard.asterisk.org/r/1294/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326855 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Terry Wilson	abd7ef817e	Merged revisions 323370 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r323370 | twilson | 2011-06-14 09:33:55 -0700 (Tue, 14 Jun 2011) | 10 lines Add rtpkeepalives back to 1.8 The RTP-engine conversion left out support for handling rtpkeepalives. This patch adds them back. (closes issue ASTERISK-17304) Reported by: lmadsen Review: https://reviewboard.asterisk.org/r/1226/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@323374 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
David Vossel	d2f16ce587	Merged revisions 317918 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r317918 | dvossel | 2011-05-06 16:06:55 -0500 (Fri, 06 May 2011) | 7 lines Fixes missing colon from To/From headers in RTCP manager events. (closes issue #18221) Reported by: clegall_proformatique Patches: 18221_1.patch uploaded by ebroad (license 878) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317920 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Terry Wilson	e9ba0cba72	Sets video mark bit on format field correctly ... This fixes a regression in the media architecture change where video frames did not have their video mark set correctly. dvossel wrote this. twilson kindly committed this, mmichelson found the bug. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313822 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
David Vossel	d760e81f37	Media Project Phase2: SILK 8khz-24khz, SLINEAR 8khz-192khz, SPEEX 32khz, hd audio ConfBridge, and other stuff ... -Functional changes 1. Dynamic global format list build by codecs defined in codecs.conf 2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf 3. Negotiation of SILK attributes in chan_sip. 4. SPEEX 32khz with translation 5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation using codec_resample.c 6. Various changes to RTP code required to properly handle the dynamic format list and formats with attributes. 7. ConfBridge now dynamically jumps to the best possible sample rate. This allows for conferences to take advantage of HD audio (Which sounds awesome) 8. Audiohooks are no longer limited to 8khz audio, and most effects have been updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT. 9. codec_resample now uses its own code rather than depending on libresample. -Organizational changes Global format list is moved from frame.c to format.c Various format specific functions moved from frame.c to format.c Review: https://reviewboard.asterisk.org/r/1104/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Paul Belanger	3556e4c2d4	Replace ast_log(LOG_DEBUG, ...) with ast_debug() ... (closes issue #18556) Reported by: kkm Review: https://reviewboard.asterisk.org/r/1071/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306258 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	c26c190711	Asterisk media architecture conversion - no more format bitfields ... This patch is the foundation of an entire new way of looking at media in Asterisk. The code present in this patch is everything required to complete phase1 of my Media Architecture proposal. For more information about this project visit the link below. https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal The primary function of this patch is to convert all the usages of format bitfields in Asterisk to use the new format and format_cap APIs. Functionally no change in behavior should be present in this patch. Thanks to twilson and russell for all the time they spent reviewing these changes. Review: https://reviewboard.asterisk.org/r/1083/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	cc0b7e7df5	Some scheduler API cleanup and improvements. ... Previously, I had added the ast_sched_thread stuff that was a generic scheduler thread implementation. However, if you used it, it required using different functions for modifying scheduler contents. This patch reworks how this is done and just allows you to optionally start a thread on the original scheduler context structure that has always been there. This makes it trivial to switch to the generic scheduler thread implementation without having to touch any of the other code that adds or removes scheduler entries. In passing, I made some naming tweaks to add ast_ prefixes where they were not there before. Review: https://reviewboard.asterisk.org/r/1007/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299091 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	feea367f89	Merged revisions 290542 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r290542 | twilson | 2010-10-05 21:35:51 -0700 (Tue, 05 Oct 2010) | 6 lines Don't try to send RTP when remote_address is null It is possible for ast_rtp_stop() to be called which will clear the remote address and cause the sendto to fail and spam warnings. Don't send in this case. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290543 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jeff Peeler	c44527e185	Merged revisions 289840 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r289840 | jpeeler | 2010-10-01 21:43:45 -0500 (Fri, 01 Oct 2010) | 29 lines Merged revisions 289798 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r289798 | jpeeler | 2010-10-01 18:01:31 -0500 (Fri, 01 Oct 2010) | 22 lines Merged revisions 289797 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines Change RFC2833 DTMF event duration on end to report actual elapsed time. The scenario here is with a non P2P early media session. The reported time length of DTMF presses are coming up short when sending to the remote side. Currently the event duration is a running total that is incremented when sending continuation packets. These continuation packets are only triggered upon incoming media from the remote side, which means that the running total probably is not going to end up matching the actual length of time Asterisk received DTMF. This patch changes the end event duration to be lengthened if it is detected that the end event is going to come up short. Review: https://reviewboard.asterisk.org/r/957/ ABE-2476 ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289841 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	4a356afb7d	Merged revisions 287895 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r287895 | russell | 2010-09-21 10:43:33 -0500 (Tue, 21 Sep 2010) | 10 lines Don't use ast_strdupa() from within the arguments to a function. (closes issue #17902) Reported by: afried Patches: issue_17902.rev1.txt uploaded by russell (license 2) Tested by: russell Review: https://reviewboard.asterisk.org/r/927/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287896 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	920f5ea8b7	Merged revisions 284477 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r284477 | twilson | 2010-09-01 13:44:36 -0500 (Wed, 01 Sep 2010) | 17 lines Fix SRTP for changing SSRC and multiple a=crypto SDP lines Adding code to Asterisk that changed the SSRC during bridges and masquerades broke SRTP functionality. Also broken was handling the situation where an incoming INVITE had more than one crypto offer. This patch caches the SRTP policies the we use so that we can change the ssrc and inform libsrtp of the new streams. It also uses the first acceptable a=crypto line from the incoming INVITE. (closes issue #17563) Reported by: Alexcr Patches: srtp.diff uploaded by twilson (license 396) Tested by: twilson Review: https://reviewboard.asterisk.org/r/878/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284479 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Leif Madsen	ea7ddb38fc	Merged revisions 283457 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r283457 | lmadsen | 2010-08-24 13:56:29 -0500 (Tue, 24 Aug 2010) | 9 lines Fix issue where TOS is no longer set on RTP packets. Fix issue where the tos is no longer being set on RTP packets through res_rtp_asterisk. (closes issue #17890) Reported by: elguero Patches: qos_18.diff uploaded by elguero (license 37) Review: https://reviewboard.asterisk.org/r/868 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283458 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	0d4a91f062	Merged revisions 280225 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r280225 | twilson | 2010-07-28 12:34:42 -0700 (Wed, 28 Jul 2010) | 3 lines Do rtp/rtcp debugging when it is turned on w/o filtering ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280226 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Tilghman Lesher	b4e18d5660	Add load priority order, such that preload becomes unnecessary in most cases ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	1e8c66e749	Fix errors where incorrect address information was printed. ... ast_sockaddr_stringiy_fmt (which is call by all ast_sockaddr_stringify* functions) uses thread-local storage for storing the string that it creates. In cases where ast_sockaddr_stringify_fmt was being called twice within the same statement, the result of one call would be overwritten by the result of the other call. This usually was happening in printf-like statements and was resulting in the same stringified addressed being printed twice instead of two separate addresses. I have fixed this by using ast_strdupa on the result of stringify functions if they are used twice within the same statement. As far as I could tell, there were no instances where a pointer to the result of such a call were saved anywhere, so this is the only situation I could see where this error could occur. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276570 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	cd4ebd336f	Add IPv6 to Asterisk. ... This adds a generic API for accommodating IPv6 and IPv4 addresses within Asterisk. While many files have been updated to make use of the API, chan_sip and the RTP code are the files which actually support IPv6 addresses at the time of this commit. The way has been paved for easier upgrading for other files in the near future, though. Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne for their hard work on this. (closes issue #17565) Reported by: russell Patches: asteriskv6-test-report.pdf uploaded by russell (license 2) Review: https://reviewboard.asterisk.org/r/743 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	41cdf6a720	Merged revisions 274157 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r274157 | mmichelson | 2010-07-06 09:29:23 -0500 (Tue, 06 Jul 2010) | 16 lines Fix problem with RFC 2833 DTMF not being accepted. A recent check was added to ensure that we did not erroneously detect duplicate DTMF when we received packets out of order. The problem was that the check did not account for the fact that the seqno of an RTP stream will roll over back to 0 after hitting 65535. Now, we have a secondary check that will ensure that the seqno rolling over will not cause us to stop accepting DTMF. (closes issue #17571) Reported by: mdeneen Patches: rtp_seqno_rollover.patch uploaded by mmichelson (license 60) Tested by: richardf, maxochoa, JJCinAZ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274164 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Paul Belanger	6012128a48	Fix rt(c)p set debug ip taking wrong argument ... Also clean up some coding errors. (closes issue #17469) Reported by: wdoekes Patches: astsvn-rtp-set-debug-ip.patch uploaded by wdoekes (license 717) Tested by: wdoekes, pabelanger git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273233 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	1a7e1aee5e	fixes logic error introduced by slin16 sip support ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271551 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	ba3d1ad680	adds support for slin16 in sip ... (closes issue #16153) Reported by: kfister Patches: 16153-1.6.2.0-rc5.patch uploaded by kfister (license 912) slin16.sip.patch.1 uploaded by malcolmd (license 924) Tested by: kfister, malcolmd git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271261 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	b00f58da25	adds speex 16khz audio support ... (closes issue #17501) Reported by: fabled Patches: asterisk-trunk-speex-wideband-v2.patch uploaded by fabled (license 448) Tested by: malcolmd, fabled, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271231 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	fcb055fb4e	addition of G.719 pass-through support ... (closes issue #16293) Reported by: malcolmd Patches: g719.passthrough.patch.7 uploaded by malcolmd (license 924) format_g719.c uploaded by malcolmd (license 924) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270940 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	857814f435	Add SRTP support for Asterisk ... After 5 years in mantis and over a year on reviewboard, SRTP support is finally being comitted. This includes generic CHANNEL dialplan functions that work for getting the status of whether a call has secure media or signaling as defined by the underlying channel technology and for setting whether or not a new channel being bridged to a calling channel should have secure signaling or media. See doc/tex/secure-calls.tex for examples. Original patch by mikma, updated for trunk and revised by me. (closes issue #5413) Reported by: mikma Tested by: twilson, notthematrix, hemanshurpatel Review: https://reviewboard.asterisk.org/r/191/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
David Vossel	51e7ee235b	fixes crash during dtmf ... During the processing of Cisco dtmf the dtmf samples were not being calculated correctly. In an attempt to determine what sample rate was being used, a NULL frame was processed which caused a crash. This patch resolves this. (closes issue #17248) Reported by: falves11 Patches: issue_17248.diff uploaded by dvossel (license 671) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264114 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	bd716c50fd	Recorded merge of revisions 254452 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines Several fixes regarding RFC2833 DTMF detection. Here is a copy and paste of the details from my request on reviewboard that dealt with these changes: Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like: seqno 1: DTMF 1 seqno 2: DTMF 1 seqno 3: DTMF 1 seqno 4: DTMF 1 seqno 6: DTMF 1 (end) seqno 5: DTMF 1 seqno 7: DTMF 1 (end) seqno 8: DTMF 1 (end) Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too: seqno 9: DTMF 1 seqno 10: DTMF 1 (end) seqno 11: DTMF 1 (end) seqno 13: DTMF 2 seqno 12: DTMF 1 (end) seqno 14: DTMF 2 seqno 15: DTMF 2 (end) seqno 16: DTMF 2 (end) seqno 17: DTMF 2 (end) In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF. Fix 2. The second change in place is to fix an issue like the following: seqno 1: DTMF 1 seqno 2: DTMF 1 seqno 3: DTMF 1 (end) *packet lost* seqno 4: DTMF 1 (end) *packet lost* seqno 5: DTMF 1 (end) *packet lost* seqno 6: DTMF 2 When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list. Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254454 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	68d1ded8dd	Only change the RTP ssrc when we see that it has changed ... This change basically reverts the change reviewed in https://reviewboard.asterisk.org/r/374/ and instead limits the updating of the RTP synchronization source to only those times when we detect that the other side of the conversation has changed the ssrc. The problem is that SRCUPDATE control frames are sent many times where we don't want a new ssrc, including whenever Asterisk has to send DTMF in a normal bridge. This is also not the first time that this mistake has been made. The initial implementation of the ast_rtp_new_source function also changed the ssrc--and then it was removed because of this same issue. Then, we put it back in again to fix a different issue. This patch attempts to only change the ssrc when we see that the other side of the conversation has changed the ssrc. It also renames some functions to make their purpose more clear. Review: https://reviewboard.asterisk.org/r/540/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Olle Johansson	e8df30b584	Improve support for RTCP reports without report blocks ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@248108 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	e469483d82	rtp timestamp to timeval calculation fix ... The rtp timestamp to timeval calculation was only accurate for 8kHz audio. This patch corrects this. Review: https://reviewboard.asterisk.org/r/468/ SWP-648 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241714 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	f59fe83c56	More 32->64 bit codec conversions. ... In the process of swapping ULAW to a place in the extended codec space, we found several unhandled cases, where a 32-bit integer was still being used to handle a codec field. Most of these have been fixed with this commit, although there is at least one case (codec_dahdi) which depends upon outside headers to be altered before a conversion can be made. (Fixes AST-278, SWP-459) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	cf87d81e9d	Merged revisions 231441 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r231441 | dvossel | 2009-11-30 11:14:08 -0600 (Mon, 30 Nov 2009) | 11 lines fixes crash caused by RTP comfort noise payload greater than 24 bytes AST-2009-010 (closes issue #16242) Reported by: amorsen Patches: issue16242.diff uploaded by oej (license 306) Tested by: amorsen, oej, dvossel ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231491 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	d8e0c58437	Expand codec bitfield from 32 bits to 64 bits. ... Reviewboard: https://reviewboard.asterisk.org/r/416/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago