If the Expire header of a SUBSCRIBE is less that our expiremin,
a log warning will be displayed.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@278619 f38db490-d61c-443f-a65b-d21fe96a405b
[RFC3265]3.1.6.1....
The notifier MAY also check that the duration in the "Expires" header
is not too small. If and only if the expiration interval is greater
than zero AND smaller than one hour AND less than a notifier-
configured minimum, the notifier MAY return a "423 Interval too
small" error which contains a "Min-Expires" header field. The "Min-
Expires" header field is described in SIP [1].
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@278536 f38db490-d61c-443f-a65b-d21fe96a405b
If Asterisk sends a 4xx error and the other side sends a CANCEl
before receiving the 4xx and responding with the ACK, Asterisk
will process the CANCEL and send a 487 Request Terminated as
a new final response to the INVITE. Since we are issuing a new
final response to the INVITE, the old one must be pretend_acked
else it will keep retransmitting.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@278234 f38db490-d61c-443f-a65b-d21fe96a405b
There are two changes here:
1. Since the externip setting can now have a port attached
to it, calling it "externip" is misleading. The option is now
documented and parsed as "externaddr." This also extends to the
"matchexterniplocally" setting. It is now documented and parsed
as "matchexternaddrlocally." The old names for the options may
still be used, but they are no longer used in the sip.conf.sample
file.
2. If no port is set for the externaddr, and UDP is the transport
to be used, then we will set the port of the externaddr to that of
the udpbindaddr. This was how things worked prior to the IPv6 merge,
so this is a regression fix.
(closes issue #17665)
Reported by: mmichelson
Patches:
17665.diff#2 uploaded by pprindeville (license 347)
Tested by: pprindeville
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@277873 f38db490-d61c-443f-a65b-d21fe96a405b
ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@277814 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277497 | mnicholson | 2010-07-16 16:18:38 -0500 (Fri, 16 Jul 2010) | 4 lines
Default to no udptl error correction so that error correction will be disabled in the event that the remote end indicates that they do not support the error correction mode we requested.
FAX-128
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@277530 f38db490-d61c-443f-a65b-d21fe96a405b
Found a unused bag of curly brackets under my table. I always wondered where
they had gone. They where indeed needed in chan_sip.c
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276989 f38db490-d61c-443f-a65b-d21fe96a405b
sip.conf configuration for the channel and for devices.
The Max-Forwards header is used to prevent loops in a SIP network. Each intermediary,
like SIP proxys and SBCs, decrement this counter and detects when it reaches zero,
at which point the SIP request is nicely killed in a SIP-friendly way.
Review: https://reviewboard.asterisk.org/r/778/
Thanks to dvossel for the review and good advice.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276951 f38db490-d61c-443f-a65b-d21fe96a405b
Related to changes from 276571, I was accidentally testing with a port set in
my configuration causing me to miss this. Also moved the TCP handling as well
to occur before build_peer is called.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276788 f38db490-d61c-443f-a65b-d21fe96a405b
MWI updates were not being sent if no messages were found in the event cache.
This was corrected since a phone may need to clear its MWI status configured
previously from another mailbox.
Upon module or sip reload, MWI updates could not be sent due to the sipsock
socket not being set early enough in reload_config. The code handling the
descriptor assignment and such has simply been moved before the call to
build_peer.
Issuing a sip reload cleared the IP address of the peer, but skipped checking
the database for registration information. The database is now checked both
for sip reload and actually reloading the module.
If a transmission occurs before the do_monitor thread has started, do not
attempt to send a signal to it.
(closes issue #17398)
Reported by: ip-rob
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276571 f38db490-d61c-443f-a65b-d21fe96a405b
ast_sockaddr_stringiy_fmt (which is call by all ast_sockaddr_stringify* functions)
uses thread-local storage for storing the string that it creates. In cases where
ast_sockaddr_stringify_fmt was being called twice within the same statement, the
result of one call would be overwritten by the result of the other call. This
usually was happening in printf-like statements and was resulting in the same
stringified addressed being printed twice instead of two separate addresses.
I have fixed this by using ast_strdupa on the result of stringify functions if
they are used twice within the same statement. As far as I could tell, there were
no instances where a pointer to the result of such a call were saved anywhere, so
this is the only situation I could see where this error could occur.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276570 f38db490-d61c-443f-a65b-d21fe96a405b
Unlike most responses, the 200 Ok to a pending INVITE Request is
acknowledged by an ACK Request. If the ACK Request for this Response is not received
the previous behavior was to immediately destroy the dialog and hangup
the channel. Now in an effort to be more RFC compliant, instead of immediately
destroying the dialog during this special case, termination is done with a BYE Request
as the dialog is technically confirmed when the 200 Ok is sent even if the ACK is
never received. The behavior of immediately hanging up the channel remains.
This only affects how dialog termination proceeds for this one special case.
RFC 3261 section 13.3.1.4
"If the server retransmits the 2xx response for 64*T1 seconds without receiving
an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is
accomplished with a BYE, as described in Section 15."
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276439 f38db490-d61c-443f-a65b-d21fe96a405b
I've been working in this function a bunch lately, and
these huge debug strings are getting annoying.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276392 f38db490-d61c-443f-a65b-d21fe96a405b
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276347 f38db490-d61c-443f-a65b-d21fe96a405b
Retransmission of packets should not be based on how many packets were
sent, but instead on a timeout period. Depending on whether or not the
packet is for a INVITE or NON-INVITE transaction, the number of packets
sent during the retransmission timeout period will be different, so
timing out based on the number of packets sent is not accurate.
This patch fixes this by removing the retransmit limit and only stopping
retransmission after a timeout period is reached. By default this
timeout period is 64*(Timer T1) for both INVITE and non-INVITE
transactions. For more information on sip timer values refer to
RFC3261 Appendix A.
Review: https://reviewboard.asterisk.org/r/749/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276219 f38db490-d61c-443f-a65b-d21fe96a405b
Some code improperly assumes that the sessions are still there, so revert the
change until I can find all of them and fix them.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276206 f38db490-d61c-443f-a65b-d21fe96a405b
Since we are only keeping the dialog around for retransmissions at this point
and there is no possibility that we are still handling RTP, go ahead and
destroy the RTP sessions. Keeping them alive for 32 past when they are used
is unnecessary and can lead to problems with having too many open file
descriptors, etc.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@275998 f38db490-d61c-443f-a65b-d21fe96a405b
It was essentially an off-by-one error. The easiest way
to fix this was to use the handy-dandy AST_NONSTANDARD_RAW_ARGS
macro to parse the pieces of the registration string out. Tested
and it works wonderfully.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@275385 f38db490-d61c-443f-a65b-d21fe96a405b
If a Via header contained an IPv6 address, we would not properly parse
the port. We would instead get the information after the first colon in
the address.
(closes issue #17614)
Reported by: oej
Patches:
diff uploaded by sperreault (license 252)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@275308 f38db490-d61c-443f-a65b-d21fe96a405b
This should fix all the CDR tests that were not passing. When they would
originate a call, all fields in the INVITE that contained the source port would
have the port set to 0. Most troubling of these was the Contact header. Tests
are passing locally now and should also pass on the bamboo build agents.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@275294 f38db490-d61c-443f-a65b-d21fe96a405b
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@274783 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines
Add option to not do a call forward on 482 Loop Detected
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Review: https://reviewboard.asterisk.org/r/764/
........
(no option for trunk, just changing the behavior)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@274284 f38db490-d61c-443f-a65b-d21fe96a405b
A failure when calling the get_destination can mean multiple things. If
the extension is not found, a 404 error is appropriate, but if the URI
scheme is incorrect, a 404 is not approperiate. This patch adds the
get_destination_result enum to differentiate between these and other failure
types. The only logical difference in this patch is that we now send a "416
Unsupported URI scheme" response instead of a "404" when the scheme is not
recognized. This indicates to the initiator of the INVITE to retry the request
with a correct URI.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@273427 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273060 | tilghman | 2010-06-29 18:15:28 -0500 (Tue, 29 Jun 2010) | 10 lines
Allow the "useragent" value to be restored into memory from the realtime backend.
This value is purely informational. It does not alter configuration at all.
(closes issue #16029)
Reported by: Guggemand
Patches:
realtime-useragent.patch uploaded by Guggemand (license 897)
Tested by: Guggemand
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@273078 f38db490-d61c-443f-a65b-d21fe96a405b
RFC 2361 section 24.4.1 send a 400 Bad Request if the request
can not be understood due to malformed syntax. Currently we
simply ignore a packet with a missing callid, to, from, or
via header. Instead of ignoring we now send the 400 Bad request.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@272981 f38db490-d61c-443f-a65b-d21fe96a405b
RFC 3261 section 8.2.2.3 states that if any unsupported options
are found in the Require header field, a "420 (Bad Extension)"
response should be sent with an Unsupported header field containing
only the unsupported options.
This is not currently being done correctly. Right now, if Asterisk
detects any unsupported sip options in a Require header the entire
list of options are returned in the Unsupported header even if some
of those options are in fact supported. This patch fixes that by
building an unsupported options character buffer when parsing the
options that can be sent with the 420 response. A unit test verifying
this functionality has been created. Some code refactoring was required.
Review: https://reviewboard.asterisk.org/r/680/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@272880 f38db490-d61c-443f-a65b-d21fe96a405b
I am doing work in this function. I noticed a large number of
coding guidline fixes that needed to be made. Rather than have
those changes distract from my functional changes I decided
to separate these into a separate patch.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@272652 f38db490-d61c-443f-a65b-d21fe96a405b
RFC3261 states that Timer A should start at 500ms (T1) by default.
In chan_sip this value initially started at 1000ms and I changed
it to 500ms recently. After doing that I noticed in my packet
captures that it still occasionally retransmitted starting at
1000ms instead of 500ms like I told it to. This occurs because
the scheduler runs in the do_monitor thread. If a new retransmission
is added while the do_monitor thread is sleeping then it may not
detect that retransmission for nearly 1000ms. To fix this I just
poke the do_monitor thread to wake up when a new packet is sent
reliably requiring retransmits. The thread then detects the new
scheduler entry and adjusts its sleep time to account for it.
Review: https://reviewboard.asterisk.org/r/747
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@272557 f38db490-d61c-443f-a65b-d21fe96a405b
Testing proved that if Asterisk sent a connected line reinvite, and
the endpoint to which the reinvite were being sent sent a reinvite, Asterisk
would not properly respond with a 491 response.
The reason is that on connected line reinvites, we set the dialog's invitestate
to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line
reinvites. For other reinvites we do not do this. Because of the current invitestate,
when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus
did not behave properly.
The fix for this is to not enter the loop detection or spiral logic in handle_request_invite
if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted,
no matter what the nature of the reinvite may have been.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@272090 f38db490-d61c-443f-a65b-d21fe96a405b
RFC 3261 section 9 states that a CANCEL has no effect on a
request to a UAS that has already given a final response. This
patch checks to make sure there is a pending invite before
allowing a CANCEL request to be processed, otherwise it responds
to the CANCEL with a "481 Call/Transaction Does Not Exist".
Review: https://reviewboard.asterisk.org/r/697/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@271977 f38db490-d61c-443f-a65b-d21fe96a405b
russell