ASTERISK-29509: Callerid not being set via AMI Originate

[Home]

Summary: ASTERISK-29509: Callerid not being set via AMI Originate

Reporter: Daniel Harper (danieleharper) Labels: fax webrtc

Date Opened: 2021-07-05 21:57:18 Date Closed: 2021-07-19 04:03:10

Priority: Minor Regression? Yes

Status: Closed/Complete Components: Core/CallerID

Versions: 16.19.0 Frequency of
Occurrence Constant

Related
Issues:

Environment: CentOS Linux release 7.9.2009 (Core) Attachments: ( 0) full

Description: When issuing an Originate via AMI with a Callerid parameter the parameter is being ignored and the callerid name is not being set.

I was testing previously on 16.18.0 but on this version the endpoints callerid was being ignored and the name an num were the extension number. I upgrade to 16.19.0 and this issue is fixed but now the callerid parameter sent via the AMI Originate is being ignored (as it was also in 16.18.0)

Comments: By: Asterisk Team (asteriskteam) 2021-07-05 21:57:20.561-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Joshua C. Colp (jcolp) 2021-07-06 03:32:08.522-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected and the location of documentation that led you to that expectation.
3. The behavior you actually encountered.

To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

[2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

By: Daniel Harper (danieleharper) 2021-07-06 18:15:35.113-0500

This is the AMI command I am sending and the response. Note that I am trying to set the Callerid to "AMI CALLERID" as per the documentation
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+ManagerAction_Originate specifically "CallerID - Caller ID to be set on the outgoing channel."

This worked as expected on asterisk version 1.4 which is the last asterisk I have used.

Sent-> Exten: 039017010301
Sent-> Callerid: AMI CALLERID
Sent-> Channel: Local/8013@tcg-queue/n
Sent-> Account: TESTJOB123
Sent-> Context: ast-test
Sent-> Action: Originate
Sent-> Priority: 1
Sent-> Timeout: 5000
Sent->
Recieved-> Response: Success
Recieved-> Message: Originate successfully queued
Recieved->

From the logs and CLI I can see that I am still getting the endpoints callerid not the callerid I requested via the Originate ...

[Jul 7 11:10:17] DEBUG[22505][C-00000006] pbx_variables.c: Function CALLERID(number) result is '251'
[Jul 7 11:10:17] DEBUG[22505][C-00000006] pbx_variables.c: Function CALLERID(name) result is 'Ext 251'
[Jul 7 11:10:17] DEBUG[22505][C-00000006] pbx.c: Launching 'NoOp'
[Jul 7 11:10:17] VERBOSE[22505][C-00000006] pbx.c: Executing [039017010301@ast-test:1] NoOp("Local/8013@tcg-queue-00000003;1", "callerid num=251 callerid name=Ext 251 ") in new stack

Previously on 16.18.0 the callerid name and number would be displayed as the endpoint number regardless of what the actual endpoint's callerid was set at hence I opened this case on the presumption that are some callerid bugs somewhere with one being fixed in the 16.19.0 release.

Happy to provide further dial plan/logs if required.

Cheers,

Daniel

By: Daniel Harper (danieleharper) 2021-07-06 18:17:01.799-0500

debug log attached
By: Daniel Harper (danieleharper) 2021-07-06 21:59:24.724-0500

Further to this in my testing I have noticed that I have to restart asterisk if I change the callerid for the endpoint as a reload isn't sufficient. Sorry this is perhaps a different issue but I bring attention to it so show that perhaps something is broken in regards to the callerid code.

I changed the callerid for endpoint 1000 to "Extension One Thousandx" <1000> ie I added the x to the end but if I make a call I get the old callerid without the x

-- Executing [039017010301@ast-test:1] NoOp("Local/8013@tcg-queue-00000000;1", "callerid num=1000 callerid name=Extension One Thousand ") in new stack

See output showing endpoint's callerid then making a call that still has the old callerid ...

devel00*CLI> pjsip show endpoint 1000

Endpoint: <Endpoint/CID.....................................> <State.....> <Channels.>
I/OAuth: <AuthId/UserName...........................................................>
Aor: <Aor............................................> <MaxContact>
Contact: <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress..................>
Identify: <Identify/Endpoint.........................................................>
Match: <criteria.........................>
Channel: <ChannelId......................................> <State.....> <Time.....>
Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......>
==========================================================================================

Endpoint: 1000/1000 In use 1 of inf
InAuth: 1000-iauth/1000
Aor: 1000 3
Transport: simpletrans udp 0 0 0.0.0.0:5060
Channel: PJSIP/1000-00000000/AgentLogin Up 00:01:25
Exten: 9008013 CLCID: "" <>

ParameterName : ParameterValue
=====================================================================
100rel : yes
@pjsip_wizard : 1000
accept_multiple_sdp_answers : false
accountcode :
acl :
aggregate_mwi : true
allow : (ulaw)
allow_overlap : true
allow_subscribe : true
allow_transfer : true
allow_unauthenticated_options : false
aors : 1000
asymmetric_rtp_codec : false
auth : 1000-iauth
bind_rtp_to_media_address : false
bundle : false
call_group :
callerid : "Extension One Thousandx" <1000>
callerid_privacy : allowed_not_screened
callerid_tag :
connected_line_method : invite
contact_acl :
context : interviewer
cos_audio : 0
cos_video : 0
device_state_busy_at : 0
direct_media : true
direct_media_glare_mitigation : none
direct_media_method : invite
disable_direct_media_on_nat : false
dtls_auto_generate_cert : No
dtls_ca_file :
dtls_ca_path :
dtls_cert_file :
dtls_cipher :
dtls_fingerprint : SHA-256
dtls_private_key :
dtls_rekey : 0
dtls_setup : active
dtls_verify : No
dtmf_mode : rfc4733
fax_detect : false
fax_detect_timeout : 0
follow_early_media_fork : true
force_avp : false
force_rport : true
from_domain :
from_user :
g726_non_standard : false
ice_support : false
identify_by : username,ip
ignore_183_without_sdp : false
inband_progress : false
incoming_mwi_mailbox :
language :
mailboxes :
max_audio_streams : 1
max_video_streams : 1
media_address :
media_encryption : no
media_encryption_optimistic : false
media_use_received_transport : false
message_context :
moh_passthrough : false
moh_suggest : default
mwi_from_user :
mwi_subscribe_replaces_unsolicited : no
named_call_group :
named_pickup_group :
notify_early_inuse_ringing : false
one_touch_recording : false
outbound_auth :
outbound_proxy :
pickup_group :
preferred_codec_only : false
record_off_feature : automixmon
record_on_feature : automixmon
refer_blind_progress : true
rewrite_contact : false
rpid_immediate : false
rtcp_mux : false
rtp_engine : asterisk
rtp_ipv6 : false
rtp_keepalive : 0
rtp_symmetric : false
rtp_timeout : 0
rtp_timeout_hold : 0
sdp_owner : -
sdp_session : Asterisk
send_connected_line : yes
send_diversion : true
send_history_info : false
send_pai : true
send_rpid : true
set_var :
srtp_tag_32 : false
stir_shaken : false
sub_min_expiry : 0
subscribe_context :
suppress_q850_reason_headers : false
t38_udptl : false
t38_udptl_ec : none
t38_udptl_ipv6 : false
t38_udptl_maxdatagram : 0
t38_udptl_nat : false
timers : yes
timers_min_se : 90
timers_sess_expires : 1800
tone_zone :
tos_audio : 0
tos_video : 0
transport : simpletrans
trust_connected_line : yes
trust_id_inbound : false
trust_id_outbound : false
use_avpf : false
use_ptime : false
user_eq_phone : false
voicemail_extension :
webrtc : no

-- Remote UNIX connection disconnected
== Manager 'dialserver' logged off from 127.0.0.1
== Manager 'dialserver' logged on from 127.0.0.1
== Manager 'dialserver' logged on from 127.0.0.1
== Manager 'dialserver' logged on from 127.0.0.1
== Manager 'dialserver' logged on from 127.0.0.1
-- Added contact 'sip:1000@192.168.2.5:56555;ob' to AOR '1000' with expiration of 300 seconds
== Endpoint 1000 is now Reachable
-- Contact 1000/sip:1000@192.168.2.5:56555;ob is now Reachable. RTT: 1.004 msec
== Manager 'mark' logged on from 127.0.0.1
-- Called 8013@tcg-queue/n
-- Executing [8013@tcg-queue:1] Queue("Local/8013@tcg-queue-00000000;2", "8013") in new stack
-- Music class requested but no musiconhold loaded.
-- Called Local/8013@agents
-- Executing [8013@agents:1] NoOp("Local/8013@agents-00000001;2", "AGENTS") in new stack
-- Executing [8013@agents:2] AgentRequest("Local/8013@agents-00000001;2", "8013") in new stack
-- Channel Local/8013@agents-00000001;2 joined 'simple_bridge' basic-bridge <d02aac61-0397-442b-a14f-8e70833dd25b>
-- <PJSIP/1000-00000000> Playing 'beep.ulaw' (language 'en')
-- Local/8013@agents-00000001;1 is ringing
-- Channel PJSIP/1000-00000000 left 'holding_bridge' agent_hold-bridge <375a69f9-ec93-4785-a4cb-6b51a9cdc8a6>
-- Channel PJSIP/1000-00000000 joined 'simple_bridge' basic-bridge <d02aac61-0397-442b-a14f-8e70833dd25b>
-- Local/8013@agents-00000001;1 connected line has changed. Saving it until answer for Local/8013@tcg-queue-00000000;2
-- Local/8013@agents-00000001;1 answered Local/8013@tcg-queue-00000000;2
-- Local/8013@tcg-queue-00000000;1 answered
-- Executing [039017010301@ast-test:1] NoOp("Local/8013@tcg-queue-00000000;1", "callerid num=1000 callerid name=Extension One Thousand ") in new stack
-- Executing [039017010301@ast-test:2] Dial("Local/8013@tcg-queue-00000000;1", "PJSIP/039017010301@mytrunk,,gH") in new stack
By: Joshua C. Colp (jcolp) 2021-07-07 03:42:22.096-0500

In regards to your comment:

"Further to this in my testing I have noticed that I have to restart asterisk if I change the callerid for the endpoint as a reload isn't sufficient. Sorry this is perhaps a different issue but I bring attention to it so show that perhaps something is broken in regards to the callerid code."

This is because you have an active call to the endpoint, until a new call is placed from the endpoint the old callerid will be used. It is not updated in realtime across all active channels from an endpoint upon configuration change.

I also think your problem is not really a problem, but the way that connected line updates and originate works. Asterisk 1.4 did not have such functionality and also had completely different agents functionality. Upon answer the agent information is given to the other side of the call, which is what is doing your dialling. One thing that comes to mind as a potential solution is to set your own variables for callerid information, and then before doing the Dial() to change callerid.
By: Daniel Harper (danieleharper) 2021-07-18 21:53:34.446-0500

I tested this and I do see the callerid set correctly in the tcg-queue context. So perhaps its is indeed the new agents functionality at play here. I am still coming to grips will all the changes since 1.4. I can workaround this issue by using a variable in the originate command. Hopefully this might help someone else.

Thanks Daniel