ast_channel_search_locked need to be made. Specifically, the caller needs to be able to
pass arbitrary data which in turn is passed to the callback. This patch addresses all
of the nested functions currently in asterisk trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
makes more sense. Where it was set before, it was impossible
to actually delay sending a CANCEL if we had not yet received
a provisional response to an INVITE.
(closes issue #13626)
Reported by: atis
Patches:
13626.patch uploaded by putnopvut (license 60)
Tested by: atis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ao2_callback and ao2_find). Currently, passing OBJ_POINTER to either
of these mandates that the passed 'arg' is a hashable object, making
searching for an ao2 object based on outside criteria difficult.
Reviewed by Russell and Mark M. via ReviewBoard:
http://reviewboard.digium.com/r/36/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
container. The OBJ_MULTIPLE flag must be provided here. Otherwise, this would
only remove a single object.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channel list calling a caller-defined callback. The callback returns non-zero
if a match is found. This should speed up some of the code that I committed
earlier today in chan_sip (which is also updated by this commit).
Reviewed by russellb and kpfleming via ReviewBoard:
http://reviewboard.digium.com/r/28/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
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
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
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
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
than what was in the invite_branch of a sip_pvt, meaning
that if a CANCEL were sent later, the branch in the CANCEL
would not match the branch in the latest INVITE sent out, leading
to some endpoints responding to the CANCEL with a 481.
(closes issue #13714)
Reported by: fnordian
Patches:
invite_branch.patch uploaded by fnordian (license 110)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- move all setting of 'needdestroy' on dialog structures into the history
- report all tags involved when a pedantic check fails on a REFER
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
necessary to allow for a sip_pvt to maintain a reference
to a sip_peer's outboundproxy even after the peer has
been freed.
(closes issue #13700)
Reported by: fnordian
Patches:
13700.patch uploaded by putnopvut (license 60)
Tested by: fnordian
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We're going to try to get time to fix this and kpfleming believes that there's code in ao2
so that we can solve it...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
