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/trunk@219451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@219304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This way, we don't always write a null byte into
byte 1 of the buffer
(closes issue #15905)
Reported by: ebroad
Patches:
freadfix.patch uploaded by ebroad (license 878)
Tested by: ebroad
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@218933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@218918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the course of this, I also found that the results of ast_gethostbyname
were being used incorrectly in both chan_iax2 and chan_sip, so both have
been fixed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Related to #12713
Patch by oej
A big thank you to file for finally fixing the transfer() dialplan application.
I've been waiting for years for this. Great work!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@216993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove unused string in sip_registry -- "random"
- Someone added a function in the middle of all forward declarations... Weird. Moved it out of that
section.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Add variable for number of known media streams instead of hardcoding in definition of sip_pvt
- Rename "text" to "codecs" - beacuse it's what it is
- Add documentation for future developers so that we make sure that we define new sdp media types
for SRTP-variants
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a problem in the function responsible for doing peer matching by
IP address and port number such that during the second pass for checking for
a peer configured with insecure=port, it would end up treating every peer as
if it had been configured that way. These changes fix the logic in the peer
IP and port comparison callback to handle insecure=port checking properly.
This problem was introduced when SIP peers were converted to astobj2. Many
thanks to dvossel for noticing this while working on another peer matching
issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@215758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@215681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we had this from the start, debugging the 'parking not using configured parkinglot'
bug would have been easier.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, the scheme passed to parse_uri can either be a
single scheme, or a list of schemes ',' delimited.
This gets rid of the whole problem of having to create
two buffers and calling parse_uri twice to check for
separate schemes.
Review: https://reviewboard.asterisk.org/r/343/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
keep-alive events are used by Sipura/Linksys for NAT keepalive.
There currently don't appear to be any problems with NAT, but
everytime a keep-alive event is received, Asterisk responds with a
"489 Bad event". This error may indicate to a user that NAT
problems exist just because this even is not supported. Now,
rather than respond with an error, the packet is consumed and
a "200 ok" is sent just to indicate we received the packet.
(issue #15084)
Patches:
chan_sip.keepalive.v1.diff uploaded by IgorG (license 20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Thank oej for pointing out the fact that sip_new did not copy parkinglot from the peer
into the newly created channel.
(closes issue #15538)
Reported by: gracedman
Patches:
2009090100_sipnewparkinglot-161.diff.txt uploaded by mvanbaak (license 7)
With mod by me to also fix callparking as well (this uploaded patch only fixed retrieving a parked call)
Tested by: gracedman, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
