https://origsvn.digium.com/svn/asterisk/trunk
................
r221432 | mnicholson | 2009-09-30 15:40:20 -0500 (Wed, 30 Sep 2009) | 17 lines
Merged revisions 221360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221360 | mnicholson | 2009-09-30 14:36:06 -0500 (Wed, 30 Sep 2009) | 10 lines
Fix SRV lookup and Request-URI generation in chan_sip.
This patch adds a new field "portinuri" to the sip dialog struct and the sip peer struct. That field is used during RURI generation to determine if the port should be included in the RURI. It is also used in some places to determine if an SRV lookup should occur.
(closes issue #14418)
Reported by: klaus3000
Tested by: klaus3000, mnicholson
Review: https://reviewboard.asterisk.org/r/369/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@221486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221266 | twilson | 2009-09-30 12:52:30 -0500 (Wed, 30 Sep 2009) | 32 lines
Merged revisions 221086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@221301 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r220906 | tilghman | 2009-09-29 14:57:37 -0500 (Tue, 29 Sep 2009) | 16 lines
Merged revisions 220873 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r220873 | tilghman | 2009-09-29 12:59:26 -0500 (Tue, 29 Sep 2009) | 9 lines
Reduce CPU usage related to building a peer merely for devicestates.
This fixes a 100% CPU problem in the SIP driver, found by profiling
the driver while the problem was occurring.
(closes issue #14309)
Reported by: pkempgen
Patches:
20090924__issue14309.diff.txt uploaded by tilghman (license 14)
Tested by: pkempgen, vrban
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@220976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219451 | dvossel | 2009-09-18 11:20:41 -0500 (Fri, 18 Sep 2009) | 20 lines
Merged revisions 219450 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219450 | dvossel | 2009-09-18 11:19:15 -0500 (Fri, 18 Sep 2009) | 14 lines
via-header branches not updated correctly on INVITE
INVITE requests must always contain a new unique branch id. When
a new branch id is created for an INVITE, the dialog's invite_branch
variable must be updated so CANCEL requests use the correct branch id.
(closes issue #15262)
Reported by: maniax
Patches:
asterisk-1.6.1.0-sip-branch.patch uploaded by tweety (license 608)
invite_new_branch_trunk.diff uploaded by dvossel (license 671)
Tested by: maniax, dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@219454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r219304 | dvossel | 2009-09-17 16:59:21 -0500 (Thu, 17 Sep 2009) | 27 lines
Merged revisions 219303 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219303 | dvossel | 2009-09-17 16:29:37 -0500 (Thu, 17 Sep 2009) | 21 lines
INVITE w/Replaces deadlock fix
This patch cleans up the locking logic in chan_sip.c's
handle_invite_replaces() function as well as making use
of ast_do_masquerade() rather than forcing the masquerade
on an ast_read(). The code had several redundant unlocks
that would result in 'freed more times than we've locked!'
errors. I cleaned these up as well as moving all the unlock
logic to the end of the function. This patch should also
resolve the issue people were having with the replacecall
channel never being unlocked with one legged calls.
(closes issue #15151)
Reported by: irroot
Patches:
invite_w_replaces_1.4.diff uploaded by dvossel (license 671)
Tested by: irroot, dvossel
Review: https://reviewboard.asterisk.org/r/371/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@219305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r218918 | file | 2009-09-16 13:31:47 -0500 (Wed, 16 Sep 2009) | 5 lines
On TCP and TLS connections do not attempt to stop retransmission of the packet internally.
This was preventing responses from being properly processed because the packet was not being found
causing handle_response to return prematurely.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@218931 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r216993 | dvossel | 2009-09-08 09:26:30 -0500 (Tue, 08 Sep 2009) | 14 lines
caller id number empty
parse_uri was not being given the correct scheme's, as
a result, uri parsing did not parse the username correctly.
One of the side effects of this is an empty caller id.
(closes issue #15839)
Reported by: ebroad
Patches:
blank_cidv2.patch uploaded by ebroad (license 878)
parse_uri_fix.diff uploaded by dvossel (license 671)
Tested by: ebroad, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@216996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r216438 | oej | 2009-09-04 16:02:34 +0200 (Fre, 04 Sep 2009) | 35 lines
Merged revisions 216430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@216645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r215758 | twilson | 2009-09-02 18:31:04 -0500 (Wed, 02 Sep 2009) | 25 lines
Merged revisions 215682 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18 lines
Re-send non-100 provisional responses to prevent cancellation
From section 13.3.1.1 of RFC 3261:
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
(closes issue #11157)
Reported by: rjain
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/315/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@215759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r215681 | dvossel | 2009-09-02 16:39:31 -0500 (Wed, 02 Sep 2009) | 10 lines
port string to int conversion using sscanf
There are several instances where a port is parsed
from a uri or some other source and converted to
an int value using atoi(), if for some reason the
port string is empty, then a standard port is used.
This logic is used over and over, so I created a function
to handle it in a safer way using sscanf().
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@215687 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r211876 | mnicholson | 2009-08-12 14:53:14 -0500 (Wed, 12 Aug 2009) | 11 lines
Make asterisk handle 423 Interval Too Short messages better.
This change uses separate values for the acceptable minimum expiry provided by the 423 error and the expiry value stored in the configuration file. Previously, the value pulled from the configuration file would be overwritten.
(closes issue #14366)
Reported by: Nick_Lewis
Patches:
sip-expiry-fix1.diff uploaded by mnicholson (license 96)
chan_sip.c-reqexpiry.patch uploaded by Nick (license 657)
Tested by: mnicholson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@211952 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r210817 | file | 2009-08-06 14:47:04 -0300 (Thu, 06 Aug 2009) | 11 lines
Accept additional T.38 reinvites after an initial one has been handled.
Discussion of this subject has yielded that it is not actually acceptable to change
T.38 parameters after the initial reinvite but declining is harsh and can cause the
fax to fail when it may be possible to allow it to continue. This patch changes things
so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
the fax a fighting chance.
(closes issue #15610)
Reported by: huangtx2009
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@210818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r208588 | mmichelson | 2009-07-24 13:31:04 -0500 (Fri, 24 Jul 2009) | 16 lines
Merged revisions 208587 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208587 | mmichelson | 2009-07-24 13:26:50 -0500 (Fri, 24 Jul 2009) | 10 lines
Only send a BYE when hanging up a channel that is up.
For cases where Asterisk sends an INVITE and receives a non 2XX final
response, Asterisk would follow the INVITE transaction by immediately
sending a BYE, which was unnecessary.
(closes issue #14575)
Reported by: chris-mac
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@208589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208548 | kpfleming | 2009-07-24 10:02:53 -0500 (Fri, 24 Jul 2009) | 8 lines
Resolve a T.38 negotiation issue left over from the udptl-updates merge.
The udptl-updates branch that was merged yesterday failed to properly send back
T.38 SDP responses with the correct error correction mode, if the incoming SDP
from the other end caused us to change error correction modes. This patch
corrects that situation.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@208549 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines
Rework of T.38 negotiation and UDPTL API to address interoperability problems
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@208468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r208388 | mmichelson | 2009-07-23 14:34:49 -0500 (Thu, 23 Jul 2009) | 24 lines
Merged revisions 208386 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208386 | mmichelson | 2009-07-23 14:24:21 -0500 (Thu, 23 Jul 2009) | 17 lines
Fix a problem where a 491 response could be sent out of dialog.
This generalizes the fix for issue 13849. The initial fix corrected the
problem that Asterisk would reply with a 491 if a reinvite were received
from an endpoint and we had not yet received an ACK from that endpoint
for the initial INVITE it had sent us. This expansion also allows Asterisk
to appropriately handle an INVITE with authorization credentials if Asterisk
had not received an ACK from the previous transaction in which Asterisk had
responded to an unauthorized INVITE with a 407.
(closes issue #14239)
Reported by: klaus3000
Patches:
14239.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@208389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r207424 | mmichelson | 2009-07-20 14:48:12 -0500 (Mon, 20 Jul 2009) | 39 lines
Merged revisions 207423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207423 | mmichelson | 2009-07-20 14:39:59 -0500 (Mon, 20 Jul 2009) | 33 lines
Answer video SDP offers properly when videosupport is not enabled.
Copied from Review board:
In issue 12434, the reporter describes a situation in which audio and video
is offered on the call, but because videosupport is disabled in sip.conf,
Asterisk gives no response at all to the video offer. According to RFC 3264,
all media offers should have a corresponding answer. For offers we do not
intend to actually reply to with meaningful values, we should still reply
with the port for the media stream set to 0.
In this patch, we take note of what types of media have been offered and
save the information on the sip_pvt. The SDP in the response will take into
account whether media was offered. If we are not otherwise going to answer
a media offer, we will insert an appropriate m= line with the port set to 0.
It is important to note that this patch is pretty much a bandage being
applied to a broken bone. The patch *only* helps for situations where video
is offered but videosupport is disabled and when udptl_pt is disabled but
T.38 is offered. Asterisk is not guaranteed to respond to every media offer.
Notable cases are when multiple streams of the same type are offered.
The 2 media stream limit is still present with this patch, too.
In trunk and the 1.6.X branches, things will be a bit different since Asterisk
also supports text in SDPs as well.
(closes issue #12434)
Reported by: mnnojd
Review: https://reviewboard.asterisk.org/r/311
Review: https://reviewboard.asterisk.org/r/313
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@207425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r206939 | dvossel | 2009-07-17 11:13:22 -0500 (Fri, 17 Jul 2009) | 20 lines
Merged revisions 206938 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206938 | dvossel | 2009-07-17 11:05:06 -0500 (Fri, 17 Jul 2009) | 14 lines
SIP incorrect From: header information when callpres is prohib
Some ITSP make use of the "Anonymous" display name to detect a
requirement to withhold caller id across the PSTN. This does
not work if the display name is "Unknown".
(closes issue #14465)
Reported by: Nick_Lewis
Patches:
chan_sip.c-callerpres.patch uploaded by Nick (license 657)
chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@206947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r206768 | dvossel | 2009-07-15 17:04:13 -0500 (Wed, 15 Jul 2009) | 8 lines
Session timer were not activated if Supported header field in INVITE had both "timer" and other options.
(closes issue #15403)
Reported by: makoto
Patches:
sip-session-timer.patch uploaded by makoto (license
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@206775 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r206702 | dvossel | 2009-07-15 15:20:01 -0500 (Wed, 15 Jul 2009) | 10 lines
callerid(num) is wrong when username is missing
A domain only sip uri <sip:123.123.123.123> would return
123.123.123.123 as callid num. Now, if the username is
missing from a uri, the callerid num field is left empty.
(closes issue #15476)
Reported by: viraptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@206705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r205985 | dvossel | 2009-07-10 16:42:10 -0500 (Fri, 10 Jul 2009) | 16 lines
SIP register not using peer's outbound proxy
If callbackextension is defined for a peer it successfully causes
a registration to occur, but the registration ignores the
outboundproxy settings for the peer. This patch allows the
peer to be passed to obproxy_get() in transmit_register().
(closes issue #14344)
Reported by: Nick_Lewis
Patches:
callbackextension_peer_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/294/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@206017 65c4cc65-6c06-0410-ace0-fbb531ad65f3
