Per RFC3325, the 'From' header is now anonymized on outgoing calls when
caller id presentation is prohibited.
TID = trust_id_outbound
PRO = Set(CALLERID(pres)=prohib)
USR = endpoint/from_user
DOM = endpoint/from_domain
PAI = YES(privacy=off), NO(not sent), PRI(privacy=full) (assumes send_pai=yes)
Conditions |Result
--------------------|----------------------------------------------------
TID PRO USR DOM |PAI FROM
--------------------|----------------------------------------------------
Y Y abc def.ghi |PRI "Anonymous" <sip:abc@def.ghi>
Y Y abc |PRI "Anonymous" <sip:abc@anonymous.invalid>
Y Y def.ghi |PRI "Anonymous" <sip:anonymous@def.ghi>
Y Y |PRI "Anonymous" <sip:anonymous@anonymous.invalid>
Y N abc def.ghi |YES <sip:abc@def.ghi>
Y N abc |YES <sip:abc@<ip_address>>
Y N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
Y N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
N Y abc def.ghi |NO "Anonymous" <sip:abc@def.ghi>
N Y abc |NO "Anonymous" <sip:abc@anonymous.invalid>
N Y def.ghi |NO "Anonymous" <sip:anonymous@def.ghi>
N Y |NO "Anonymous" <sip:anonymous@anonymous.invalid>
N N abc def.ghi |YES <sip:abc@def.ghi>
N N abc |YES <sip:abc@<ip_address>>
N N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
N N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
ASTERISK-25791 #close
Reported-by: Anthony Messina
Change-Id: I2c82a5ca1413c2c00fb62ea95b0ae8e97af54dc9
If the PJSIP_HEADER dialplan function adds a PAI or RPID header and send_rpid
or send_pai is set, res_pjsip_caller_id attemps to retrieve, parse and modify
the header added by the dialplan function. Since the header added by the
dialplan function is generic string, there are no virtual functions to parse
the uri and we get a segfault when we try. Since the modify, was really only
an overwrite, we now just delete the old header if it was type PJSIP_H_OTHER
and recreate it.
This raises a question for another time though: What should happen with
duplicate headers? Right now res_pjsip_header_funcs doesn't check for dups
so if it's session supplement is loaded after res_pjsip_caller_id's (or any
other module that adds headers), there'll be dups in the message.
ASTERISK-25337 #close
Change-Id: I5e296b52d30f106b822c0eb27c4c2b0e0f71c7fa
Apparently some endpoints attempt to send a reINVITE before completing the
initial INVITE transaction. In this case PJSIP responds appropriately to
the reINVITE with a 491 INVITE request pending. Unfortunately chan_pjsip
is using the initial INVITE transaction state to determine if an INVITE is
the initial INVITE or a reINVITE. Since the initial INVITE transaction
has not been confirmed yet chan_pjsip thinks the reINVITE is an initial
INVITE and starts another PBX thread on the channel. The extra PBX thread
ensures that hilarity ensues.
* Fix checks for a reINVITE on incoming requests to look for the presence
of a to-tag instead of the initial INVITE transaction state.
* Made caller_id_incoming_request() determine what to do if there is a
channel on the session or not. After a channel is created it is too late
to just store the new party id on the session because the session's party
id has already been copied to the channel's caller id.
ASTERISK-25404 #close
Reported by: Chet Stevens
Change-Id: Ie78201c304a2b13226f3a4ce59908beecc2c68be
The res_pjsip modules were manually checking both name and number
presentation values when there is a function that determines the combined
presentation for a party ID struct. The function takes into account if
the name or number components are valid while the manual code rarely
checked if the data was even valid.
* Made use ast_party_id_presentation() rather than manually checking party
ID presentation values.
* Ensure that set_id_from_pai() and set_id_from_rpid() will not return
presentation values other than what is pulled out of the SIP headers. It
is best if the code doesn't assume that AST_PRES_ALLOWED and
AST_PRES_USER_NUMBER_UNSCREENED are zero.
* Fixed copy paste error in add_privacy_params() dealing with RPID
privacy.
* Pulled the id->number.valid test from add_privacy_header() and
add_privacy_params() up into the parent function add_id_headers() to skip
adding PAI/RPID headers earlier.
* Made update_connected_line_information() not send out connected line
updates if the connected line number is invalid. Lower level code would
not add the party ID information and thus the sent message would be
unnecessary.
* Eliminated RAII_VAR usage in send_direct_media_request().
Review: https://reviewboard.asterisk.org/r/4472/
........
Merged revisions 432892 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer. The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision. Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.
* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.
* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.
* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.
ASTERISK-24700 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4417/
........
Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, the Remote-Party-ID header took the position of
"If caller name and number are not explicitly allowed, then they are private"
and P-Asserted-Identity took the position of
"Caller name and number are only private if marked explicitly so"
Now both mechanisms of conveying party identification use the former approach.
........
Merged revisions 421778 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421783 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A calls B
B answers
B SIP attended transfers to C
C answers, B and C can see each other's connected line information
B completes the transfer
A has number but no name connected line information about C
while C has the full information about A
I examined the incoming and outgoing party id information handling of
chan_pjsip and found several issues:
* Fixed ast_sip_session_create_outgoing() not setting up the configured
endpoint id as the new channel's caller id. This is why party A got
default connected line information.
* Made update_initial_connected_line() use the channel's CALLERID(id)
information. The core, app_dial, or predial routine may have filled in or
changed the endpoint caller id information.
* Fixed chan_pjsip_new() not setting the full party id information
available on the caller id and ANI party id. This includes the configured
callerid_tag string and other party id fields.
* Fixed accessing channel party id information without the channel lock
held.
* Fixed using the effective connected line id without doing a deep copy
outside of holding the channel lock. Shallow copy string pointers can
become stale if the channel lock is not held.
* Made queue_connected_line_update() also update the channel's
CALLERID(id) information. Moving the channel to another bridge would need
the information there for the new bridge peer.
* Fixed off nominal memory leak in update_incoming_connected_line().
* Added pjsip.conf callerid_tag string to party id information from
enabled trust_inbound endpoint in caller_id_incoming_request().
AFS-98 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3913/
........
Merged revisions 421400 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421403 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds Path support to chan_pjsip in res_pjsip_path.c with minimal
additions in res_pjsip_registrar.c to store the path and additions in
res_pjsip_outbound_registration.c to enable advertisement of path
support to registrars and intervening proxies.
Path information is stored on contacts and is enabled via Address of
Record (AoRs) and Registration configuration sections.
While adding path support, it became necessary to be able to add SIP
supplements that handled messages outside of sessions, so a framework
for handling these types of hooks was added in parallel to the
already-existing session supplements and several senders of
out-of-dialog requests were refactored as a result.
(closes issue ASTERISK-21084)
Review: https://reviewboard.asterisk.org/r/3050/
........
Merged revisions 405565 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fromuser option is used to explicitly set the user within the From header. The
res_pjsip_caller_id module did not take this setting into account when determining
if the From header could be modified or not.
(closes issue ASTERISK-22866)
Reported by: Anthony Messina
........
Merged revisions 402891 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Connected line updates are now only sent out if an actual update needs to occur.
This happens under the following conditions:
1. The endpoint we are sending to is trusted.
2. Either a P-Asserted-Identity or Remote Party-ID header needs to be added/sent.
3. The connected id's number and name are valid.
Also added an SDP when an update is sent out.
(closes issue AST-1212)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2831/
........
Merged revisions 398806 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The general gist is to have a clear boundary between old SIP stuff
and new SIP stuff by having the word "SIP" for old stuff and "PJSIP"
for new stuff. Here's a brief rundown of the changes:
* The word "Gulp" in dialstrings, functions, and CLI commands is now
"PJSIP"
* chan_gulp.c is now chan_pjsip.c
* Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*"
* All files that were "res_sip*" are now "res_pjsip*"
* The "res_sip" directory is now "res_pjsip"
* Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*"
* The configuration file is now "pjsip.conf" instead of "res_sip.conf"
* The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP"
* CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as
the starting word instead of "sip"
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
George Joseph
Richard Mudgett
Rodrigo Ramírez Norambuena
Joshua Colp
Kinsey Moore
Mark Michelson
Kevin Harwell