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
SIP request method in the Cseq: header. Asterisk did not handle this
properly, but with this patch, all is well.
(closes issue #12834)
Reported by: tobias_e
Patches:
12834.patch uploaded by putnopvut (license 60)
Tested by: tobias_e
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@123333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
rtcachefriends was set was done too soon (needed to be done inside build_peer,
not just as a flag to build_peer).
Also, fullcontact needed to be reconstructed, because realtime separates the
embedded ';' into multiple fields.
(closes issue #12722)
Reported by: barthpbx
Patches:
20080525__bug12722.diff.txt uploaded by Corydon76 (license 14)
Tested by: barthpbx
(Much of the discussion happened on #asterisk-dev for diagnosing this issue)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@118251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
