asterisk

Commit Graph

Author	SHA1	Message	Date
Mark Michelson	c946be82a9	Add INFO to our allowed methods so that endpoints know they may send it to us. AST-223 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@200513 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	ed94be12f0	Additional updates to AST-2009-001 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@199138 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	67928d88a9	'iax show peer blah' now outputs whether or not peer 'blah' is in trunk mode or not. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197620 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	590408dca3	Allow for media to arrive from an alternate source when responding to a reinvite with 491. When we receive a SIP reinvite, it is possible that we may not be able to process the reinvite immediately since we have also sent a reinvite out ourselves. The problem is that whoever sent us the reinvite may have also sent a reinvite out to another party, and that reinvite may have succeeded. As a result, even though we are not going to accept the reinvite we just received, it is important for us to not have problems if we suddenly start receiving RTP from a new source. The fix for this is to grab the media source information from the SDP of the reinvite that we receive. This information is passed to the RTP layer so that it will know about the alternate source for media. Review: https://reviewboard.asterisk.org/r/252 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197588 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Eliel C. Sardanons	26cec158af	Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue #15194) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197562 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	eb2a672328	Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting. The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated (or it passes through unauthenticated) the proper nat flag is set. (closes issue #13823) Reported by: dimas git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@197466 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	e79b7e3c8d	Fix a bug where using immediate with mISDN caused a cause code of 16 to get sent back instead of 1 if the 's' extension did not exist. (closes issue #12286) Reported by: lmamane git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@196116 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	620bae6924	Sign problem calculating timestamp for iax frame leads to no audio on the receiving peer. There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement. (closes issue #15032) Reported by: guillecabeza Patches: chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380) Tested by: guillecabeza (closes issue #14216) Reported by: Andrey Sofronov git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@195991 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	64c1093e14	Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered. (issue #13545) Reported by: davidw (issue #14244) Reported by: mbnwa git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@195448 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	ac71a26c0f	Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited. (closes issue #13569) Reported by: bkw918 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@195095 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	ca3481edb9	IAX2 REGAUTH loop IAX was not sending REGREJ to terminate invalid registrations. Instead it sent another REGAUTH if the authentication challenge failed. This caused a loop of REGREQ and REGAUTH frames. (Related to Security fix AST-2009-001) (closes issue #14867) Reported by: aragon Tested by: dvossel (closes issue #14717) Reported by: mobeck Patches: regauth_loop_update_patch.diff uploaded by dvossel (license 671) Tested by: dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194873 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	1e410cdfc5	Update to previous IAX2 "Ghost" Channels patch. Fixed some comments made on reviewboard for the previous patch. (issue #14207) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194685 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	616674ae68	IAX2 "Ghost" Channels There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away. (closes issue #14207) Reported by: clive18 Review: https://reviewboard.asterisk.org/r/246/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194557 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	7aa29c797a	Fix a race condition where a reinvite could trigger a 482 response. The loop detection/spiral detection code in chan_sip used the owner channel's state as a criterion for determining if the incoming INVITE is a looped request. The problem with this is that the INVITE-handling code happens in a different thread than the thread that marks the owner channel as being up. As a result, if a reinvite were to come in very quickly, say from another Asterisk on the same LAN, it was possible for the reinvite to arrive before the owner channel had been set to the up state. This patch corrects the problem by using the invitestate of the sip_pvt instead, since that can be guaranteed to be set correctly by the time the reinvite arrives. Since there is a switch statement further in the INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate of the sip_pvt in case we should actually be treating the channel as if it were up already. (closes issue #12215) Reported by: jpyle Patches: 12215_confirmed.patch uploaded by mmichelson (license 60) Tested by: lmadsen git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@194484 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	63c0dca7bd	Set the invitestate to INV_CANCELLED only if we are actually sending a SIP CANCEL. The problem was that the hangup code was setting the invitestate too early. The result of this was that we would always send a CANCEL request, even if it was not an appropriate time to do so (e.g. we have not yet received a provisional response for our INVITE). Note that this same fix had been applied to trunk and the 1.6.X branches starting with revision 155467. This is why you will see this revision being blocked from those places. AST-216 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193880 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	4d64b0c937	Sent wrong message to clear a call we started if the other end has not responed yet. In the state MISDN_CALLING (i.e. SETUP was sent but no answer has arrived yet), it is not allowed to clear the call with RELEASE_COMPLETE. It must be cleared with DISCONNECT. A RELEASE_COMPLETE is only allowed as an answer to a SETUP. (See Q.931 ch. 5.3.2, 5.3.2.a, 5.3.2.b) Patches: chan-misdn-ccstate7.patch uploaded by customer. JIRA ABE-1862 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193613 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	3d0faa34ca	"misdn show config" segfaults asterisk, if no MSN lists (closes issue #14976) Reported by: alecdavis Patches: misdn_config.diff.txt uploaded by alecdavis (license 585) Tested by: alecdavis, FabienToune git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193262 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	0971bac5bc	Give a more helpful message when an incoming call's dialed extension does not match. Added the dialed extension and context to the chan_misdn messages warning that the dialed number cannot be matched in the dialplan. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@193050 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	c57efbe571	Eliminate repetition of fullcontact during reconstruction. If the fullcontact field appears in both the sippeers and the sipregs table, then during reconstruction of the field, it will otherwise be doubled. (closes issue #14754) Reported by: Alexei Gradinari Patches: 20090506__bug14754.diff.txt uploaded by tilghman (license 14) Tested by: lmadsen git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192932 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	202bc9464e	Update some old logic to stop both begin and end DTMF frames from reaching the core if rfc2833 is not enabled. (closes issue #15036) Reported by: dimas Patches: v1-15036.patch uploaded by dimas (license 88) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192633 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	dcb712422a	global mohinterpret setting is ignored mohinterpret and mohsuggest global variables were not copied over during build_users and build_peers. (closes issue #14728) Reported by: dimas Patches: v1-14728.patch uploaded by dimas (license 88) Tested by: dimas, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@192213 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	c2d8897257	SIP Response 410 maps to cause code 22 (or 23), not 1. (closes issue #14993) Reported by: BigJimmy Patches: causepatch uploaded by BigJimmy (license 371) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191559 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	f8b1da1872	Allow H.323 to compile with FDLEAK checking enabled. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@191220 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	03eb22fe76	Remove a bogus ast_channel_unlock(). git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@190356 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	a8a55273cf	Fix a bug in chan_local glare hangup detection. If both sides of a Local channel were hung up at around the same time it was possible for one thread to destroy the local private structure and have the other thread immediately try to remove the already freed structure from the local channel list. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@190286 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	a1b5f4a67d	Make chan_h323 respect packetization settings Previously, packetization settings were ignored and now they are not. A new config option 'autoframing' has been added to mirror the way chan_sip handles it. Turning on the autoframing option (available both as a global option or per peer) overrides the local settings with the remote packetization settings. Testing was performed with varying packetization levels with the following codecs: ulaw, alaw, gsm, and g729. (closes issue #12415) Reported by: pj Patches: 2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7), modified by me git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189991 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Doug Bailey	100aa13ae2	Clean up problem with manager implementation of mmap where it was not testing against MAP_FAILED response. Got rid of shadowed variable used in processign the mmap results. Change test of mmap results to compare against MAP_FAILED git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189391 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	5405c62098	Fixed autologoff in agents.conf not working when agent logs in via AgentLogin app An agent logs in by calling an extension that calls the AgentLogin app. In agents.conf ackcall=always is set, so when they get a call they have the choice to either acknowledge it or ignore it. autologoff=10 is set as well, so if the agent ignores the call over 10sec one may assume that the agent should be logged out (and in this case hungup on as well), but this was not happening. (closes issue #14091) Reported by: evandro Patches: autologoff.diff uploaded by dvossel (license 671) Review: http://reviewboard.digium.com/r/225/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189203 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	55e28f890d	Modifed/added some debug messages. JIRA ABE-1835 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@189134 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	df2bc7d715	Fix a bug where a value used to create the channel name was bogus. This commit fixes the scenario where an incoming call is authenticated using a peer entry. Previously the channel name was created using either the username setting from the sip.conf entry or the IP address that the call came from. Now the channel name will be created using the peer name itself. This commit will not change the way the channel name is generated for users or friends. (closes issue #14256) Reported by: Nick_Lewis Patches: chan_sip.c-chname.patch uploaded by Nick (license 657) Tested by: Nick_Lewis, file git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188946 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	bf5b92f004	Fix a situation where the DAHDI channel private structure lock was not unlocked when it should have been. (issue AST-210) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188937 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	611cf94f90	Only update realtime, if global option rtupdate != false (closes issue #14885) Reported by: deepesh Patches: 20090413__bug14885.diff.txt uploaded by tilghman (license 14) Tested by: deepesh git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188835 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	4b6846a9dd	Only disable mISDN DSP if Asterisk DSP is enabled. Leave jitter setting alone. JIRA ABE-1835 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188833 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	4c6e1bd0a5	National prefix inserted even when caller ID not available When the caller ID is restricted, the expected behavior is for the caller id to be blank. In chan_dahdi, the national prefix is placed onto the callers number even if its restricted (empty) causing the caller id to be the national prefix rather than blank. (closes issue #13207) Reported by: shawkris Patches: national_prefix.diff uploaded by dvossel (license 671) Review: http://reviewboard.digium.com/r/220/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@188646 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	3c027b6378	Fix module embedding for chan_h323. Include libchanh323.a in the modules.link file so that all the symbols can be resolved at link time. (closes issue #11966) Reported by: dome git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187962 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	9b0c55768a	Support "signaling" in addition to "signalling". The sample configuration file has references to both spellings. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187865 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	a4e46eb871	Handle a SIP race condition (reinvite before an ACK) properly. RFC 5047 explains the proper course of action to take if a reINVITE is received before the ACK from a previous invite transaction. What we are to do is to treat the reINVITE as if it were both an ACK and a reINVITE and process it normally. Later, when we receive the ACK we had been expecting, we will ignore it since its CSeq is less than the current iseqno of the sip_pvt representing this dialog. (closes issue #13849) Reported by: klaus3000 Patches: 13849_v2.patch uploaded by mmichelson (license 60) Tested by: mmichelson, klaus3000 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187484 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	1cb43cfa75	Permit zero-length text messages in SIP. (Related to an issue posted to the -users list, subject "AEL2, BASE64_DECODE and hexadecimal") git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@187362 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	89e29bfdc9	Fix a bug where DAHDI/Zaptel channels would not properly switch formats when requested Don't offer AST_FORMAT_SLINEAR on DAHDI/Zaptel channels... while it could provide a slight performance benefit, the translation core in Asterisk has some flaws when a channel driver offers multiple raw formats. this fix is much simpler than fixing the translation core to solve that issue (although that will be done later). git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186458 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	6dbc379d01	ensure that the buffer passed to DAHDI_SET_BUFINFO is fully initialized git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186081 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	24fa699663	Merged revisions 186056 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r186056 \| tilghman \| 2009-04-02 12:02:18 -0500 (Thu, 02 Apr 2009) \| 2 lines Fix for AST-2009-003 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186059 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	0487d30a98	Avoid multiple warning messages in SIP, due to this column not existing git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186057 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	090f081e41	the DAHDI_GETCONF, DAHDI_SETCONF and DAHDI_GET_PARAMS ioctls were recently corrected to show that they do, in fact, read data from userspace as part of their work. due to this fix, valgrind now reports a number of cases where chan_dahdi passed an uninitialized (or partially) buffer to these ioctls, which could lead to unexpected behavior. this patch corrects chan_dahdi to ensure that buffers passed to these ioctls are always fully initialized. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185952 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	36c92eec0e	Fixes issue with dropped calles due to re-Invite glare and re-Invites never executing after a 491 Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well. (closes issue #12013) Reported by: alx Review: http://reviewboard.digium.com/r/213/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185845 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	36a68f792e	Use AST_SCHED_DEL_SPINLOCK instead of manually using the logic. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185531 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Brooks	a2933fefef	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> git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185362 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	63ca43071e	Update the channel allocation method documentation. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185121 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	76bfa1d8ef	Make chan_misdn BRI TE side normally defer channel selection to the NT side. Channel allocation collisions are not handled by chan_misdn very well. This patch simply avoids the problem for BRI only. For PRI, allocation collisions are still possible but less likely since there are simply more channels available and each end could use a different allocation strategy. misdn.conf options available: te_choose_channel - Use to force the TE side to allocate channels. method - Specify the channel allocation strategy. (closes issue #13488) Reported by: Christian_Pinedo Patches: isdn_lib.patch.txt uploaded by crich Tested by: crich, siepkes, festr git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185120 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	df192b77df	Improve our handling of T38 in the initial INVITE from a device. We now answer with matching media streams to what is requested. If an INVITE is received with both a T38 and RTP media stream this means we answer with both. For any outgoing calls created as a result of this inbound one no T38 is requested in the initial INVITE. Instead if we start receiving udptl packets we trigger a reinvite on the outbound side. (closes issue #12437) Reported by: marsosa Tested by: pinga-fogo, okrief, file, afu Review: http://reviewboard.digium.com/r/208/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184947 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	0f37862a87	Fix an issue where nat=yes would not always take effect for the RTP session on outgoing calls. If calls were placed using an IP address or hostname the global nat setting was copied over but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP actions. (closes issue #14546) Reported by: acunningham git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184565 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago

1 2 3 4 5 ...

4713 Commits (a42ff13c97fc4c975dd1f531ea120f4c20fe90db)