the calling party when subscribed to the state of an extension that is ringing.
This has some limitations which are documented in sip.conf.sample.
(closes issue #13827)
Reported by: seanbright
Patches:
issue13827.patch uploaded by seanbright (license 71)
Reviewed by: russellb
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
along the way, change tags used in configure script, menuselect-deps and code for various dependencies to be consistently named
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
remotesecret => our password for a remote service
secret => our authentication when someone calls us
Secret => still has both functions if remotesecret is not used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
GCC 4.3.2 to complain that the passed argument will always evaluate to
true. So to get things to compile, disable assert when building
chan_usbradio.so.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
silly to have a bunch of case statements with duplicated
code in each case. Instead, just use the built-in fallthrough
capability of case statements and reduce the code to
a single instance
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove a comment that says that the monitor thread is the only one that
ever touches these objects. This is no longer the case with TCP. Also,
I would eventually like to get the scheduler in its own thread, so this
is just a poor assumption to make.
- Note that reference counting of these objects with respect to scheduler
entries is not complete. There are some leaked references when deleting
scheduler entries.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
messages alerting that a channel is being ignored
if the PROC_DAHDI_NOCHAN option is set in process_dahdi.
(closes issue #13759)
Reported by: smurfix
Patches:
dahdi.patch uploaded by smurfix (license 547)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
type and port arguments. This is necessary because when building our From
and Contact headers, we need to be absolutely sure that we are placing our
source port there and not the peer's source port.
(closes issue #12761)
Reported by: asbestoshead
Patches:
patch-chan-sip-contact-port.txt uploaded by asbestoshead (license 455)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
fail for that peer since sip_alloc will allocate a sip_pvt with
a default transport of UDP. This change resets the socket type
immediately after allocating the sip_pvt in sip_send_mwi_from_peer,
so that the proceeding call to create_addr_from_peer does not fail
right away. The socket data from the peer is properly copied to
the sip_pvt in create_addr_from_peer.
(closes issue #13710)
Reported by: andrew53
Patches:
sip_notify_use_tcp.patch uploaded by andrew53 (license 519)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to remove any parameters from the string so that name
resolution succeeds.
(closes issue #13727)
Reported by: fnordian
Patches:
resolvewithouturiparameter.patch uploaded by fnordian (license 110)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) rename 'struct server_args' to 'struct ast_tcptls_session_args', to follow coding guidelines
2) make ast_make_file_from_fd() static and rename it to something that indicates what it really is for (again coding guidelines)
3) rename address variables inside 'struct ast_tcptls_session_args' to be more descriptive (dare i say it... coding guidelines)
4) change ast_tcptls_client_start() to use the new 'remote_address' field of the session args for the destination of the connection, and use the 'local_address' field to bind() the socket to the proper source address, if one is supplied
5) in chan_sip, ensure that we pass in the PP address we are bound to when creating outbound (client) connections, so that our connections will appear from the correct address
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Additional comments on TCP/TLS implementation
- Some additions for new drafts/rfcs (no new functionality really, mostly documentation)
- Other random small fixes
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for more details of this command.
(closes issue #13326)
Reported by: ib2
Patches:
bug13326_trunk_20080822.diff uploaded by snuffy (license 35)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
odd that a channel would be named after the originating port.
For endpoints that always include ":5060" as part
of the From: header, it will mean that you have a ton of
channels with names like "SIP/5060-3ea38a8b."
I am boldly moving forward with this change in trunk, but I'm
not touching other branches with this one since this definitely
would qualify as a behavior change. If there is a problem with
this commit, and I haven't seen the obvious reason why you'd want
to name the channel after the port from which the call originated,
then please feel free to revert this
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
