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 |