The problem was that these variables were being appended to the list of vars
on the sip_pvt every time a re-registration or re-subscription came in.
Since it's just a waste of memory to put them there unless the request was an
INVITE, then the fix is to check the request type before copying the vars.
(closes issue #14037)
Reported by: marvinek
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"I guess that having only ip-phones in mind is not a good approach. Since it is
possible to have a sip proxy connected to asterisk we could receive a 407
(unauthorized) or 483 (too many hops) as response and dialog ending would not be
a good behavior."
So modified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160480 65c4cc65-6c06-0410-ace0-fbb531ad65f3
fails, and the resulting integer is garbage. Thus, we must initialize the
integer and check it afterwards for success.
(closes issue #14000)
Reported by: folke
Patches:
asterisk-sipbg-sscanf-1.4.22.diff uploaded by folke (license 626)
asterisk-sipbg-sscanf-1.6.0.1.diff uploaded by folke (license 626)
asterisk-sipbg-sscanf-trunk-r159896.diff uploaded by folke (license 626)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@159808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
section 15 of RFC 3261, we should terminate a dialog if we
receive a 481 or 408 in response to our BYE. Since I am aware
of at least one phone manufacturer who may sometimes send a
404 as well, I am being liberal and saying that any 4XX response
to a BYE should result in a terminated dialog.
(closes issue #12994)
Reported by: pabelanger
Patches:
12994.patch uploaded by putnopvut (license 60)
Closes AST-129
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that ast_call() fails. For incoming SIP channels, this was causing
us to send a 603 instead of a 486 when the call-limit was reached on
the destination channel.
(closes issue #13867)
Reported by: still_nsk
Patches:
13867.diff uploaded by putnopvut (license 60)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
function. Not setting the invite state correctly on the call was
resulting in the Record application leaving empty files. I also
have updated the doxygen comment next to the declaration of the
INV_EARLY_MEDIA constant to reflect that we also use this state
when we *send* a 18X response to an INVITE.
(closes issue #13878)
Reported by: nahuelgreco
Patches:
sip-early-media-recording-1.4.22.patch uploaded by nahuelgreco (license 162)
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
workspace. To signal an error (and no change to the workspace), -1 should be
returned instead.
(closes issue #13340)
Reported by: kryptolus
Patches:
20080827__bug13340__2.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@146799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: MVF
Tested by: neutrino88, urzedo, murf, thiagofernandes
Many thanks to neutrino88 for this patch, which
solves a problem whereby channels get a CANCEL
request, respond to it properly, but end up
in a hung state, infinitely being rescheduled.
This fix is a bit crude, in that catches the
problem at a rather late phase, but it may
prevent infinite rescheduling problems that
might still arise.
It might have been better to find out why,
in the course of protocol handling, the channel
was not destroyed, but we leave that to
future generations.
Many thanks to urzedo and thiagofernandes for
their work in verifying that the patch code
indeed is being executing, and averting the
problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
improve the security of various installations. As this does not change
any default behavior, it is not classified as a direct security fix for
anything within Asterisk, but may help PBX admins better secure their
SIP servers.
(closes issue #11776)
Reported by: ibc
Patches:
20080829__bug11776.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142865 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the media to be natively bridged, use the jointcapability
instead of the peercapability.
It seems that the intent of using the peercapability was to
expand the choice of codecs for the call to increase the
chances of being able to native bridge the channels. The
problem is that if a codec were settled on for the native
bridge and that wasn't a codec that was configured to be used
by Asterisk for that peer, then Asterisk would send a
REINVITE with no codecs in the SDP which is a bug no matter
how you slice it.
(closes issue #13076)
Reported by: ramonpeek
Patches:
13076.patch uploaded by putnopvut (license 60)
Tested by: tbelder
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
remote tag of an endpoint once a dialog has
been confirmed. Up until that point, it is possible
and legal for the far-end to send provisional
responses with a different To: tag each time. With
this patch applied, these provisional messages
will not cause a matching problem.
(closes issue #11536)
Reported by: ibc
Patches:
11536v2.patch uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caused port 5060 to always be used when dialing
a peer if no explicit port was specified. This
broke the behavior of implicitly using the port
from which the peer registered if no port is
specified. This commit fixes the logic flaw.
(closes issue #13424)
Reported by: mdu113
Patches:
13424.patch uploaded by putnopvut (license 60)
Tested by: mdu113
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in a string to Dial(), it is not ignored.
(closes issue #13355)
Reported by: acunningham
Patches:
13355v2.patch uploaded by putnopvut (license 60)
Tested by: acunningham
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in pedantic mode. The problem was that the wrong
tags would be compared depending on the direction
of the call.
(closes issue #13353)
Reported by: flefoll
Patches:
chan_sip.c.br14.139015.patch-refer-pedantic uploaded by flefoll (license 244)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of a completely unrelated function to determine whether the scheduler should
be run or not. This would have caused the scheduler to not run in cases where
it should have. Also, leave a note about another scheduler issue that needs
to be addressed at some point.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, a spiraled INVITE would cause a 482
Loop Detected to be sent to the caller. With this change,
if a potential loop is detected, the Request-URI is inspected
to see if it has changed from what was originally received. If
pedantic mode is on, then this inspection is fully RFC 3261
compliant. If pedantic mode is not on, then a string comparison
is used to test the equality of the two R-URIs.
This has been tested by using OpenSER to rewrite the R-URI
and send the INVITE back to Asterisk.
(closes issue #7403)
Reported by: stephen_dredge
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
seems to be in regards to an error message when retransmit fails. This
is frequently misunderstood as a failure of Asterisk, not a failure of
the network to reach the other party.
This document tries to assist the Asterisk user in sorting out these
issues by explaining the logic and pointing at some possible
causes. Hopefully, we will get other questions now :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@132645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
route set for the call.
----
This comment was added a while ago and today it hit me badly.
/* OEJ: Possible issue that may need a check:
If we have a proxy route between us and the device,
should we care about resolving the contact
or should we just send it?
*/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@128950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #10927)
Reported by: murf
Tested by: murf, deeperror
(closes issue #12907)
Reported by: falves11
Tested by: murf, falves11
(closes issue #11849)
Reported by: greyvoip
As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.
Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.
(closes issue #11093)
Reported by: rossbeer
Tested by: greyvoip, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
also fail if we don't get the very same precious ACK. Based on patch by tsearle, with
my own additions.
(closes issue #12951)
Reported by: tsearle
Patches:
busy_retransmit.patch uploaded by tsearle (license 373)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@126516 65c4cc65-6c06-0410-ace0-fbb531ad65f3
