Previously, only the "data" field of the sip_pkt created during __sip_reliable_xmit
was freed when XMIT_ERROR was returned by __sip_xmit. When retrans_pkt was called,
this inevitably resulted in the reading and writing of freed memory.
XMIT_ERROR is a condition meaning that we don't want to attempt resending the packet
at all. The proper action to take is to remove the scheduler entry we just created,
free the packet's data as well as the packet itself, and unlink it from the list of
packets on the sip_pvt structure.
(closes issue #14455)
Reported by: Nick_Lewis
Patches:
14455.patch uploaded by mmichelson (license 60)
Tested by: Nick_Lewis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178205 | file | 2009-02-24 11:16:07 -0400 (Tue, 24 Feb 2009) | 9 lines
Skip check for extension when subscribing for MWI.
Since the remote side is not actually subscribing to a specific extension when
subscribing for MWI just skip the check to see if the extension exists. They can't use it
to specify the mailbox either since we require configuration of that in sip.conf
(closes issue #14531)
Reported by: festr
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous implementation of T38 faxdetect resulted in both sides of the
call jumping to a fax extension when both sides had 't38pt_udptl=yes' and
'faxdetect=yes' in sip.conf and a 'fax' extension in the current context.
This revision will jump to a 'fax' extension on incoming calls only.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is required to create a UDPTL structure in create_addr_from_peer() to handle the
scenario where 't38pt_udptl=yes' is not defined in the [general] section of sip.conf but
is defined the peer's context. I tested this patch by enabling t38pt_udptl in the
[general] section on one system and only enabling t38pt_udptl in a peer's context on
the system sending a fax. Without the patch, the sending system will fail to initiate
T38 negotiation with the warning message, "No way to add SDP without an UDPTL structure".
When this patch is applied the sending side will successfully initiate T38 negotiation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176426 | tilghman | 2009-02-16 18:49:22 -0600 (Mon, 16 Feb 2009) | 10 lines
After a 'sip reload', qualifies for realtime peers weren't immediately
restarted, instead waiting until the next registration. We're now
caching the qualify across a reload/restart and starting the qualify
immediately upon loading the peer.
(closes issue #14196)
Reported by: pdf
Patches:
20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
Tested by: pdf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176029 | file | 2009-02-16 11:33:53 -0400 (Mon, 16 Feb 2009) | 9 lines
Don't have the Via header stored as a stringfield as it can change often during the lifetime of a dialog.
This issue crept up with subscriptions on the AA50. When an outgoing NOTIFY is sent a new branch value
is created and the Via header is changed to reflect it. Since this was a stringfield a new spot in the
pool was used for the value while the old was left untouched/unused. If the current pool was full a new
pool was created. This would cause memory usage to increase steadily.
(issue #AA50-2332)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) It had numerous coding guidelines violations with regards to formatting.
2) It allocated memory using ast_calloc() that was never freed.
3) It didn't check for failure from the allocation.
4) It used sprintf() and strcat() to build the result, doing zero checking to
prevent writing past the end of the provided buffer.
The function also lacks API documentation, but that has not been addressed in
this commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds passthrough, file recording and file playback support for the codecs listed above, with negotiation over SIP/SDP supported. Due to Asterisk's current limitation of treating a codec/bitrate combination as a unique codec, only G.722.1 at 32 kbps and G.722.1C at 48 kbps are supported.
Along the way, some related work was done:
1) The rtpPayloadType structure definition, used as a return result for an API call in rtp.h, was moved from rtp.c to rtp.h so that the API call was actually usable. The only previous used of the API all was chan_h323.c, which had a duplicate of the structure definition instead of doing it the right way.
2) The hardcoded SDP sample rates for various codecs in chan_sip.c were removed, in favor of storing these sample rates in rtp.c along with the codec definitions there. A new API call was added to allow retrieval of the sample rate for a given codec.
3) Some basic 'a=fmtp' parsing for SDP was added to chan_sip, because chan_sip *must* decline any media streams offered for these codecs that are not at the bitrates that we support (otherwise Bad Things (TM) would result).
Review: http://reviewboard.digium.com/r/158/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174282 | mmichelson | 2009-02-09 11:11:05 -0600 (Mon, 09 Feb 2009) | 12 lines
Don't do an SRV lookup if a port is specified
RFC 3263 says to do A record lookups on a hostname
if a port has been specified, so that's what we're
going to do. See section 4.2.
(closes issue #14419)
Reported by: klaus3000
Patches:
patch_chan_sip_nosrvifport_1.4.23.txt uploaded by klaus3000 (license 65)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174301 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174082 | dhubbard | 2009-02-06 17:36:03 -0600 (Fri, 06 Feb 2009) | 5 lines
check ast_strlen_zero() before calling ast_strdupa() in sip_uri_headers_cmp()
and sip_uri_params_cmp()
The reporter didn't actually upload a properly-formed patch, instead a
modified chan_sip.c file was uploaded. I created a patch to determine the
changes, then modified the suggested changes to create a proper fix. The
summary above is a complete description of the changes.
(closes issue #13547)
Reported by: tecnoxarxa
Patches:
chan_sip.c.gz uploaded by tecnoxarxa (license 258)
Tested by: tecnoxarxa
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173967 | file | 2009-02-06 13:14:15 -0400 (Fri, 06 Feb 2009) | 4 lines
Some clients do not put the call-id for replaces at the beginning, so support it being anywhere in the string.
(closes issue #14350)
Reported by: fhackenberger
........
r173968 | file | 2009-02-06 13:15:01 -0400 (Fri, 06 Feb 2009) | 2 lines
Remove a debug message I put in by accident.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
supporting devices. The devices (snoms, specifically) need to receive a SIP
URI instead of just an extension. This adds that functionality.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also, implement a private cause code (as suggested by Tilghman). This works with
chan_sip, but doesn't propagate through chan_local.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Also, change a function in app.c to return a userful value instead of always returning 0.
Patch by fnordian, changed by Corydon76 and myself.
This does not close the bug report, as fnordian had an additional change we're still discussing.
(related to issue #14059)
Reported by: fnordian
Patches:
chan_sip_hfield.patch uploaded by fnordian (license 110)
20090116__bug14059.diff.txt uploaded by Corydon76 (license 14)
Tested by: fnordian, Corydon76, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172169 | oej | 2009-01-29 09:48:18 +0100 (Tor, 29 Jan 2009) | 16 lines
Make sure that we always add the hangupcause headers. In some cases, the owner was disconnected before we checked for the cause.
This patch implements a temporary storage in the pvt and use that instead.
The code is based on ideas from code from Adomjan in issue #13385 (Add support for Reason: header)
Thanks to Klaus Darillion for testing!
(closes issue #14294)
related to issue #13385
Reported by: klaus3000 and adomjan
Patches:
bug14294b.diff uploaded by oej (license 306)
Based on 20080829_chan_sip.c-q850reason_header.patch uploaded by adomjan (license 487)
Tested by: oej, klaus3000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Merged revisions 171527 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r171527 | oej | 2009-01-27 15:33:20 +0100 (Tis, 27 Jan 2009) | 13 lines
Use the same branch tag in CANCEL as in INVITE
Originally putnopvut implemented some changes in revision 142079 that according to the bug report seemed to have worked then, but somehow fails now.
I guess code, as humans, get old and forget stuff. Anyway, this bug caused CANCEL not to work with picky systems.
Thanks Fredrik for pointing out where the bug in the SIP messaging was.
(closes issue #14346)
Reported by: oej
Patches:
bug14346.diff uploaded by oej (license 306)
Tested by: oej
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@171528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ccesario on IRC pointed out that his sip peers were not displayed
properly when he would issue the command "sip show peers." The problem
was that the onlymatchonip field was used to determine if the endpoint
was a "peer" or "user." The tricky part is that a "friend" is supposed
to be treated as both a "user" and a "peer" but the logic would not allow
"friends" to show up as "peers" since onlymatchonip was set to FALSE
for friends.
I have modified the sip_peer structure to more explicitly keep track of
what type endpoint it is so that the various manager and CLI commands
will display the expected information
Reported by ccesario via IRC
Tested by ccesario
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an ast_str expands to hold more data, any pointers that were pointing
to the data prior to the expansion will be pointing at invalid memory. This
change makes such pointers used in chan_sip.c instead be offsets from the
beginning of the string so that the same math may be applied no matter where
in memory the string resides.
To help ease this transition, a macro called REQ_OFFSET_TO_STR has been added
to chan_sip.c so that given a sip_request and an offset, the string at that
offset is returned.
(closes issue #14220)
Reported by: riksta
Tested by: putnopvut
Review http://reviewboard.digium.com/r/126/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168975 | mmichelson | 2009-01-16 16:42:13 -0600 (Fri, 16 Jan 2009) | 18 lines
Account for possible NULL pointer when we receive a 408 in response to a REGISTER
It may be that by the time we receive a reply to a REGISTER request, the attempt has
timed out and thus the registry structure pointed to by the corresponding sip_pvt has
gone away. This situation was handled properly for a 200 OK response, but the 408
case assumed that the sip_registry struct was non-NULL, thus potentially causing a crash
This commit fixes this assumption and prints out a message to the console if we should
receive a late 408 response to a REGISTER
(closes issue #14211)
Reported by: aborghi
Patches:
14211.diff uploaded by putnopvut (license 60)
Tested by: aborghi
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 1.4 and 1.6.0, the sip_request structure had a statically
allocated buffer to hold the text of the request. There was a check in the
add_line function to not attempt to write the line into the buffer if we
did not have room for it.
In trunk and Asterisk versions starting with 1.6.1, an expandable ast_str
structure is used to hold the text. Since it may grow to fit an arbitrarily
sized string, this check in add_line is no longer valid.
I found this oddity while attempting to fix issue #14220; however, I do not
believe that this is the fix for that issue since the output supplied by the
reporter did not contain the warning message that would be printed had this
condition been satisfied.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168725 65c4cc65-6c06-0410-ace0-fbb531ad65f3
