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
It fixes authentication with Primus in Canada, and has been in use for a very long
time without causing problems with any other providers.
(closes issue AST-36)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
redirect of two channels which are natively bridged will preserve audio
on both channels. This prevents a problem with Asterisk not re-inviting
due to one of the channels having being a zombie.
(closes issue #12513)
Reported by: mneuhauser
Patches:
asterisk-1.4-114602_restore-RTP-on-fixup.patch uploaded by mneuhauser (license 425)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These changes make sure that the reference count for sip_peer objects properly
reflects the fact that the peer is sitting in the scheduler for a scheduled
callback for qualifying peers or for expiring registrations. Without this, it
was possible for these callbacks to happen at the same time that the peer was
being destroyed. This was especially likely to happen with realtime peers, and
for people making use of the realtime prune CLI command.
(closes issue #9520)
Reported by: kryptolus
Committed patch by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we should not send a BYE.
(closes issue #12392)
Reported by: fnordian
Patches:
chan_sip.patch uploaded by fnordian (license 110) with small modification from me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
