ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer. If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer. Reentrancy issues could result if the
task does not execute with the right serializer.
The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936). A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().
However, there are a few places where this unexpected behavior is still
required to avoid deadlocks. The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer. I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().
* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous(). ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in. Both functions
behave the same if the current thread is not a SIP servant.
* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.
ASTERISK_26806
Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3
This patch does three things associated with the initial incoming INVITE
request URI.
1) Add access to the full initial incoming INVITE request URI.
2) We were not setting DNID on incoming PJSIP channels. The DNID is the
user portion of the initial incoming INVITE Request-URI. The value is
accessed by reading CALLERID(dnid).
3) Fix CHANNEL(pjsip,target_uri) documentation.
* The initial incoming INVITE request URI is now available using
CHANNEL(pjsip,request_uri).
* Set the DNID on PJSIP channel creation so CALLERID(dnid) can return the
initial incoming INVITE request URI user portion.
* CHANNEL(pjsip,target_uri) now correctly documents that the target URI is
the contact URI.
* Refactored print_escaped_uri() out of channel_read_pjsip() to handle
pjsip_uri_print() error condition when the buffer is too small.
ASTERISK-27478
Change-Id: I512e60d1f162395c946451becb37af3333337b33
Create local_tag and remote_tag in CHANNEL info to get tag from From and
To headers of a SIP dialog.
ASTERISK-27220
Change-Id: I59b16c4b928896fcbde02ad88f0e98922b15d524
If an SDP answer hasn't been sent yet, it's legal to change it.
This is required for PJSIP_DTMF_MODE to work correctly, and can
also have use in the future for updating codecs too.
ASTERISK-27209 #close
Change-Id: Idbbfb7cb3f72fbd96c94d10d93540f69bd51e7a1
This function is a replica of SIPDtmfMode, allowing the DTMF mode of a
PJSIP call to be modified on a per-call basis
ASTERISK-27085 #close
Change-Id: I20eef5da3e5d1d3e58b304416bc79683f87e7612
The construction of the returned string assumed incorrectly that the
supplied buffer would always be initialized as an empty string. If it is
not an empty string we could overrun the supplied buffer by the length of
the non-empty buffer string plus one. It is also theoreticaly possible
for the supplied buffer to be overrun by a string terminator during a read
operation even if the supplied buffer is an empty string.
* Fix the assumption that the supplied buffer would already be an empty
string. The buffer is not guaranteed to contain an empty string by all
possible callers.
* Fix string terminator buffer overrun potential.
Change-Id: If6a0806806527678c8554b1dcb34fd7808aa95c9
This introduces the ability for PJSIP code to specify filtering flags
when retrieving PJSIP contacts. The first flag for use causes the
query code to only retrieve contacts that are not unreachable. This
change has been leveraged by both the Dial() process and the
PJSIP_DIAL_CONTACTS dialplan function so they will now only attempt
calls to contacts which are not unreachable.
ASTERISK-26281
Change-Id: I8233b4faa21ba3db114f5a42e946e4b191446f6c
When querying for PJSIP specific information using the dialplan
function CHANNEL() it is possible that the underlying session
will no longer have a channel associated with it. This is
most likely to occur when the RTCP HEP module attempts to get
the channel name. If this happens then a crash will occur.
This change just adds a check that the channel exists on the
session before querying it.
ASTERISK-26857
Change-Id: I113479cffff6ae64cf8ed089e9e1565223426f01
The CHANNEL() dialplan function implementation for PJSIP allows
querying of PJSIP specific information. This used the channel
passed in to get the PJSIP session and associated information.
It is possible for this channel to be masqueraded and end
up as a different channel type by the time the information
request is actually acted upon.
This change retrieves the PJSIP session safely and accesses
data from it (including channel). This provides a guarantee
that the session and channel will not be altered when the
request is being acted upon.
ASTERISK-26673
Change-Id: I335e12b89e1820cafdd92b3e7526b8ba649eb7e6
This updates func_channel.c and main/message.c to use a generic xpointer
include instead of including info from each channel driver. Now the
name attribute of info is CHANNEL or CHANNEL_EXAMPLES to be included in
documentation for func_channel. Setting the name attribute of info to
MessageToInfo or MessageFromInfo causes it to be included in the
MessageSend application and AMI action.
Change-Id: I89fd8276a3250824241a618009714267d3a8d1ea
* Following the example of the PJSIP channel driver, the channel
technology specific documentation has been moved to the respective
channel drivers that provide that functionality. This has the benefit
of locating the documentation of items with those modules that provide
it.
* Examples of using the CHANNEL function for both standard items as well
as for PJSIP have been added.
* The 'max_forwards' standard item has been documented.
Change-Id: Ifaa79a232c8ac99cf8da6ef6cc7815d398b1b79b
This patch adds a new PJSIP specific dialplan function,
PJSIP_SEND_SESSION_REFRESH. When invoked on a PJSIP channel, the media
session will be refreshed via either an UPDATE or re-INVITE request.
When used in conjunction with the PJSIP_MEDIA_OFFER dialplan function,
the formats in use on a PJSIP channel can be re-negotiated and changed
dynamically after call setup.
ASTERISK-26277 #close
Change-Id: Ib98fe09ba889aafe26d58d32f0fd1323f8fd9b1b
Added the ability to show channel statistics to chan_pjsip (cli_functions.c)
Moved the existing 'pjsip show channel(s)' functionality from
pjsip_configuration to cli_functions.c. The stats needed chan_pjsip's
private header so it made sense to move the existing channel commands as well.
Now using stasis_cache_dump to get the channel snapshots rather than retrieving
all endpoints, then getting each one's channel snapshots. Much more efficient.
Change-Id: I03b114522126d27434030b285bf6d531ddd79869
This patch adds a new option to the CHANNEL function that allows for the
extraction of the SIP call-id. It is used in conjunction with the 'pjsip'
option, and will return the Call-ID of the INVITE request that established
the PJSIP channel.
ASTERISK-25352
Change-Id: I278d1f8bcfe3a53c5aa1dadebc14e92b0abd476a
This fixes autological comparison warnings in the following:
* chan_skinny: letohl may return a signed or unsigned value, depending on the
macro chosen
* func_curl: Provide a specific cast to CURLoption to prevent mismatch
* cel: Fix enum comparisons where the enum can never be negative
* enum: Fix comparison of return result of dn_expand, which returns a signed
int value
* event: Fix enum comparisons where the enum can never be negative
* indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
negative
* presencestate: Use the actual enum value for INVALID state
* security_events: Fix enum comparisons where the enum can never be negative
* udptl: Don't bother to check if the return value from encode_length is less
than 0, as it returns an unsigned int
* translate: Since the parameters are unsigned int, don't bother checking
to see if they are negative. The cast to unsigned int would already blow
past the matrix bounds.
* res_pjsip_exten_state: Use a temporary value to cache the return of
ast_hint_presence_state
* res_stasis_playback: Fix enum comparisons where the enum can never be
negative
* res_stasis_recording: Add an enum value for the case where the recording
operation is in error; fix enum comparisons
* resource_bridges: Use enum value as opposed to -1
* resource_channels: Use enum value as opposed to -1
Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4533.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'pjsip_get_dest_info' function is used to determine if the signaling transport
of the dialog is secure or not. This function was added in PJSIP 2.3 and does not
exist in earlier versions.
This configure check allows Asterisk to build and run with older versions at the
loss of the 'secure' argument for the PJSIP CHANNEL dialplan function. Usage of
this argument will require upgrading to PJSIP 2.3.
ASTERISK-24665 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4329/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PJSIP_AOR dialplan function allows inspection of configured AORs including
what contacts are currently bound to them.
The PJSIP_CONTACT dialplan function allows inspection of contacts in existence.
These can include both externally added (by way of registration) or permanent
ones.
ASTERISK-24341
Reported by: xrobau
Review: https://reviewboard.asterisk.org/r/4308/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430179 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, we were using the PJSIP dialog's secure flag
to determine if a secure transport was being used. Unfortunately,
the dialog's secure flag was only set if a SIPS URI were in use,
as required by RFC 3261 sections 12.1.1 and 12.1.2. What we're interested
in is not dialog security, but transport security. This code change
switches to a model where we use the dialog's target URI to determine
what transport would be used to communicate, and then check if that
transport is secure.
AST-1450 #close
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/4277
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling PJSIP_MEDIA_OFFER on a non-PJSIP channel is hazardous to your health.
It will treat the channels as a PJSIP channel, eventually hitting an ao2 error,
FRACKing on assertion error, and quite likely crashing.
This patch adds checks to the read/write callbacks that ensure that the channel
technology is of type 'PJSIP' before attempting to operate on the channel.
#SIPit31
ASTERISK-24382 #close
Reported by: Matt Jordan
........
Merged revisions 424621 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds CHANNEL read support for chan_pjsip. This allows the dialplan
to use the CHANNEL function on a chan_pjsip channel to obtain run-time
information about the channel from the PJSIP channel driver and the PJSIP
stack. This includes:
* RTP information, including source/destination media addresses, whether or
not the media is secure, held, and other properties.
* RTCP information. This includes sets of parseable information, as well as
individual statistic attriutes.
* PJSIP information. This includes URIs, local/remote signalling addresses,
whether or not the signalling is secure, and other properties.
* The endpoint name. This can be used in conjunction with the PJSIP_ENDPOINT
function to obtain more detailed endpoint information.
Review: https://reviewboard.asterisk.org/r/3038/
........
Merged revisions 403618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
