Number redirect

Hi Team

Please, can you assist?

Our redirect seems to be working, however, the inbound CLI in not presenting. It shows the 0105010174 number for an inbound call.

The calling number should remain the calling number, the destination divert happens in the background to another destination.

You should be seeing a missed call on the receiving handset from the calling party (A) number, not the dialled (B) number.

Please see, Verbose results from our FreePBX 14.0.3.2 and SET CID print screen.

Please note most tasks should be handled through the GUI.
You can access the GUI by typing one of the above IPs in to your web browser.
For support please visit:
Training & Support | FreePBX - Let Freedom Ring

[root@fnetdbn-ast02 ~]# asterisk -rvvvvvvg | grep 0105010174
– Executing [0105010174@from-trunk:1] Set(“SIP/10.31.200.3-0000841a”, “__DIRECTION=INBOUND”) in new stack
– Executing [0105010174@from-trunk:2] Gosub(“SIP/10.31.200.3-0000841a”, “sub-record-check,s,1(in,0105010174,dontcare)”) in new stack
– Executing [in@sub-record-check:1] NoOp(“SIP/10.31.200.3-0000841a”, “Inbound Recording Check to 0105010174”) in new stack
– Executing [in@sub-record-check:4] Gosub(“SIP/10.31.200.3-0000841a”, “recordcheck,1(dontcare,in,0105010174)”) in new stack
– Executing [0105010174@from-trunk:3] Gosub(“SIP/10.31.200.3-0000841a”, “app-blacklist-check,s,1()”) in new stack
– Executing [0105010174@from-trunk:4] Set(“SIP/10.31.200.3-0000841a”, “__FROM_DID=0105010174”) in new stack
– Executing [0105010174@from-trunk:5] Set(“SIP/10.31.200.3-0000841a”, “CDR(did)=0105010174”) in new stack
– Executing [0105010174@from-trunk:6] ExecIf(“SIP/10.31.200.3-0000841a”, “0 ?Set(CALLERID(name)=none)”) in new stack
– Executing [0105010174@from-trunk:7] Set(“SIP/10.31.200.3-0000841a”, “__MOHCLASS=”) in new stack
– Executing [0105010174@from-trunk:8] Set(“SIP/10.31.200.3-0000841a”, “__REVERSAL_REJECT=FALSE”) in new stack
– Executing [0105010174@from-trunk:9] GotoIf(“SIP/10.31.200.3-0000841a”, “1?post-reverse-charge”) in new stack
– Goto (from-trunk,0105010174,11)
– Executing [0105010174@from-trunk:11] NoOp(“SIP/10.31.200.3-0000841a”, “”) in new stack
– Executing [0105010174@from-trunk:12] Set(“SIP/10.31.200.3-0000841a”, “__CALLINGNAMEPRES_SV=allowed_not_screened”) in new stack
– Executing [0105010174@from-trunk:13] Set(“SIP/10.31.200.3-0000841a”, “__CALLINGNUMPRES_SV=allowed_not_screened”) in new stack
– Executing [0105010174@from-trunk:14] Set(“SIP/10.31.200.3-0000841a”, “CALLERID(name-pres)=allowed_not_screened”) in new stack
– Executing [0105010174@from-trunk:15] Set(“SIP/10.31.200.3-0000841a”, “CALLERID(num-pres)=allowed_not_screened”) in new stack
– Executing [0105010174@from-trunk:16] NoOp(“SIP/10.31.200.3-0000841a”, “CallerID Entry Point”) in new stack
– Executing [0105010174@from-trunk:17] Goto(“SIP/10.31.200.3-0000841a”, “app-setcid,10,1”) in new stack
– Executing [10@app-setcid:1] NoOp(“SIP/10.31.200.3-0000841a”, “(Johann Victor 0634052391) Changing cid to 0315736200 <0105010174>”) in new stack
– Executing [10@app-setcid:3] Set(“SIP/10.31.200.3-0000841a”, “CALLERID(num)=0105010174”) in new stack
– Executing [s@macro-user-callerid:2] Set(“SIP/10.31.200.3-0000841a”, “AMPUSER=0105010174”) in new stack
– Executing [s@macro-user-callerid:4] ExecIf(“SIP/10.31.200.3-0000841a”, “1?Set(__REALCALLERIDNUM=0105010174)”) in new stack
– Executing [s@macro-user-callerid:29] Set(“SIP/10.31.200.3-0000841a”, “CALLERID(number)=0105010174”) in new stack
– Executing [s@macro-user-callerid:33] Set(“SIP/10.31.200.3-0000841a”, “CDR(cnum)=0105010174”) in new stack
– Executing [s@macro-outbound-callerid:3] ExecIf(“SIP/10.31.200.3-0000841a”, “0?Set(REALCALLERIDNUM=0105010174)”) in new stack
– Executing [s@macro-outbound-callerid:20] Set(“SIP/10.31.200.3-0000841a”, “CDR(outbound_cnum)=0105010174”) in new stack
– Executing [s@macro-dialout-trunk:20] ExecIf(“SIP/10.31.200.3-0000841a”, “0?Set(CONNECTEDLINE(name,i)=CID:0105010174)”) in new stack
– Executing [s@macro-dialout-trunk:21] ExecIf(“SIP/10.31.200.3-0000841a”, “0?Set(CONNECTEDLINE(name,i)=CID:(Hidden)0105010174)”) in new stack

Our SBC 10.31.200.2 show the CDR result as follows :

Channel Data

Name Value
caps 1=1;2=1;3=1;4=1;5=1;6=1
flags 0=1;1=1;3=1;37=1;38=1;40=1;43=1;48=1;53=1;105=1;111=1;112=1;121=1
state CS_REPORTING
direction inbound
state_number 11

Variables

Name Value
uuid 8d318a1c-a2d0-42a8-a6fd-750a65ab93ea
billsec 4
waitsec 2
DP_MATCH 06340523910634052391
billmsec 3880
billusec 3879995
duration 14
last_app bridge
last_arg sofia/gateway/02dd5c79-1e12-4548-a9f2-4dad8b161280/0634052391
sip_cseq 102
waitmsec 2480
waitusec 2480002
answersec 10
call_uuid 8d318a1c-a2d0-42a8-a6fd-750a65ab93ea
caller_id “0315736200” <0105010174>
direction inbound
dtmf_type rfc2833
end_epoch 1537982904
end_stamp 2018-09-26 19:28:24
mduration 14180
read_rate 8000
sip_allow INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
uduration 14180003
DIALSTATUS SUCCESS
answermsec 10300
answerusec 10300008
end_uepoch 1537982904356808
read_codec PCMU
rtp_use_pt 0
session_id 6191887
sip_to_tag j2vDZj3NKBNBa
sip_to_uri [email protected]
write_rate 8000
bridge_uuid 68711b98-70bc-4d10-9059-5a24ba21ff23
presence_id [email protected]
progresssec 0
signal_bond 68711b98-70bc-4d10-9059-5a24ba21ff23
sip_call_id [email protected]:5060
sip_full_to ;tag=j2vDZj3NKBNBa
sip_req_uri [email protected]
sip_to_host 10.31.200.2
sip_to_user 0634052391
start_epoch 1537982890
start_stamp 2018-09-26 19:28:10
write_codec PCMU
answer_epoch 1537982900
answer_stamp 2018-09-26 19:28:20
bridge_epoch 1537982892
bridge_stamp 2018-09-26 19:28:12
channel_name sofia/fnetdbn-sip/[email protected]
flow_billsec 14
hangup_cause NORMAL_CLEARING
max_forwards 70
progressmsec 0
progressusec 0
rtp_use_ssrc 2489123338
sip_from_tag as671a8269
sip_from_uri [email protected]
sip_full_via SIP/2.0/UDP 10.31.200.4:5060;branch=z9hG4bK3805c90d
sip_req_host 10.31.200.2
sip_req_user 0634052391
sip_via_host 10.31.200.4
sip_via_port 5060
start_uepoch 1537982890176805
switch_m_sdp v=0 o=- 225446727 98365099 IN IP4 41.162.57.148 s=- c=IN IP4

41.162.57.148 t=0 0 m=audio 20774 RTP/AVP 0 101 a=rtpmap:0
PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15|
|switch_r_sdp|v=0 o=root 2007112040 2007112040 IN IP4 10.31.200.4 s=Asterisk PBX
14.5.0 c=IN IP4 10.31.200.4 t=0 0 m=audio 14396 RTP/AVP 0 8 18
101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18
G729/8000 a=fmtp:18 annexb=no a=rtpmap:101
telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150|
|answer_uepoch|1537982900476813|
|bridge_uepoch|1537982892656807|
|flow_billmsec|14180|
|flow_billusec|14180003|
|hold_accum_ms|0|
|inherit_codec|true|
|sip_from_host|10.31.200.4|
|sip_from_user|0105010174|
|sip_full_from|“0315736200” ;tag=as671a8269|
|bridge_channel|sofia/neotel-poil/0634052391|
|call_direction|outbound|
|last_bridge_to|68711b98-70bc-4d10-9059-5a24ba21ff23|
|local_media_ip|10.31.200.2|
|progress_epoch|0|
|sip_authorized|true|
|sip_network_ip|10.31.200.4|
|sip_term_cause|16|
|sip_user_agent|FPBX-14.0.3.2(14.5.0)|
|ep_codec_string|CORE_PCM_MODULE.PCMU@8000h@20i@64000b,CORE_PCM_MODULE.PCMA@8000h@20i@64000b
,mod_bcg729.G729@8000h@20i@8000b|
|hold_accum_usec|0|
|last_hold_epoch|0|
|originated_legs|68711b98-70bc-4d10-9059-5a24ba21ff23;Outbound Call;0634052391|
|progress_uepoch|0|
|remote_media_ip|10.31.200.4|
|resurrect_epoch|0|
|sip_contact_uri|[email protected]:5060|
|sip_received_ip|10.31.200.4|
|sip_term_status|200|
|audio_media_flow|sendrecv|
|callee_id_number|0634052391|
|continue_on_fail|true|
|last_bridge_role|originator|
|last_hold_uepoch|0|
|local_media_port|32444|
|originate_causes|68711b98-70bc-4d10-9059-5a24ba21ff23;NONE|
|resurrect_uepoch|0|
|rtp_audio_in_mos|4.50|
|sip_contact_host|10.31.200.4|
|sip_contact_port|5060|
|sip_contact_user|0105010174|
|sip_from_display|0315736200|
|sip_network_port|5060|
|sip_via_protocol|udp|
|video_media_flow|sendrecv|
|hangup_cause_q850|16|
|progress_mediasec|2|
|remote_media_port|14396|
|rtp_audio_recv_pt|0|
|rtp_local_sdp_str|v=0 o=FreeSWITCH 1537950448 1537950450 IN IP4
10.31.200.2 s=FreeSWITCH c=IN IP4 10.31.200.2 t=0 0 m=audio 32444
RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101
telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv|
|sip_acl_authed_by|fnet-dbn|
|sip_received_port|5060|
|hold_accum_seconds|0|
|original_read_rate|8000|
|progress_mediamsec|2480|
|progress_mediausec|2480002|
|rtp_use_codec_name|PCMU|
|rtp_use_codec_rate|8000|
|rtp_use_timer_name|soft|
|sofia_profile_name|fnetdbn-sip|
|advertised_media_ip|10.31.200.2|
|bridge_hangup_cause|NORMAL_CLEARING|
|current_application|bridge|
|hangup_after_bridge|true|
|original_read_codec|PCMU|
|profile_start_epoch|1537982890|
|profile_start_stamp|2018-09-26 19:28:10|
|rtp_use_codec_ptime|20|
|endpoint_disposition|ANSWER|
|profile_start_uepoch|1537982890176805|
|progress_media_epoch|1537982892|
|progress_media_stamp|2018-09-26 19:28:12|
|rtp_use_codec_string|G7221@32000h,G7221@16000h,G722,PCMU,PCMA,G729|
|originate_disposition|SUCCESS|
|progress_media_uepoch|1537982892656807|
|recovery_profile_name|fnetdbn-sip|
|rtp_2833_recv_payload|101|
|rtp_2833_send_payload|101|
|ignore_display_updates|true|
|rtp_audio_in_raw_bytes|24940|
|rtp_use_codec_channels|1|
|sip_from_user_stripped|0105010174|
|sip_hangup_disposition|recv_bye|
|sip_local_network_addr|10.31.200.2|
|rtp_audio_in_flaw_total|0|
|rtp_audio_out_raw_bytes|99760|
|current_application_data|sofia/gateway/02dd5c79-1e12-4548-a9f2-4dad8b161280/0634052391|
|last_sent_callee_id_name|Outbound Call|
|rtp_audio_in_media_bytes|24940|
|rtp_audio_in_packet_count|145|
|rtp_audio_out_media_bytes|99760|
|last_sent_callee_id_number|0634052391|
|rtp_audio_in_mean_interval|20.00|
|rtp_audio_out_packet_count|580|
|rtp_audio_rtcp_octet_count|0|
|proto_specific_hangup_cause|sip:200|
|rtp_audio_rtcp_packet_count|0|
|rtp_last_audio_codec_string|PCMU@8000h@20i@1c|
|rtp_audio_in_largest_jb_size|0|
|rtp_audio_in_cng_packet_count|0|
|rtp_audio_in_jitter_loss_rate|0.00|
|rtp_audio_in_dtmf_packet_count|0|
|rtp_audio_in_jitter_burst_rate|0.00|
|rtp_audio_in_skip_packet_count|439|
|rtp_audio_out_cng_packet_count|0|
|rtp_audio_in_flush_packet_count|0|
|rtp_audio_in_media_packet_count|145|
|rtp_audio_in_quality_percentage|100.00|
|rtp_audio_out_dtmf_packet_count|0|
|rtp_audio_out_skip_packet_count|0|
|rtp_audio_in_jitter_max_variance|33.33|
|rtp_audio_in_jitter_min_variance|11.11|
|rtp_audio_in_jitter_packet_count|0|
|rtp_audio_out_media_packet_count|580|
|sip_bye_h_X-Asterisk-HangupCause|Normal Clearing|
|sip_bye_h_X-Asterisk-HangupCauseCode|16|

Application Log

Name Data
set sip_h_X-accountcode=
set call_direction=outbound
set hangup_after_bridge=true
set effective_caller_id_name=
set effective_caller_id_number=
set inherit_codec=true
set ignore_display_updates=true
set callee_id_number=0634052391
set continue_on_fail=true
bridge sofia/gateway/02dd5c79-1e12-4548-a9f2-4dad8b161280/0634052391

Call Flow: Attributes

Name Value


dialplan XML
unique-id f43a8fec-f6dc-4ead-b158-6ef92b0565fd
profile_index 1

Call Flow: Extension: Attributes

Name Value


name FirstNet
number 0634052391

Call Flow: Extension: Application

Name Data


set sip_h_X-accountcode=${accountcode}
set call_direction=outbound
set hangup_after_bridge=true
set effective_caller_id_name=${outbound_caller_id_name}
set effective_caller_id_number=${outbound_caller_id_number}
set inherit_codec=true
set ignore_display_updates=true
set callee_id_number=0634052391
set continue_on_fail=true
bridge sofia/gateway/02dd5c79-1e12-4548-a9f2-4dad8b161280/0634052391

Call Flow: Caller Profile

Name Value


ani 0105010174
uuid 8d318a1c-a2d0-42a8-a6fd-750a65ab93ea
aniii
rdnis
source mod_sofia
context default
dialplan XML
username 0105010174
chan_name sofia/fnetdbn-sip/[email protected]
originatee
origination Array
network_addr 10.31.200.4
callee_id_name Outbound Call
caller_id_name 0315736200
callee_id_number 0634052391
caller_id_number 0105010174
destination_number 0634052391

Call Flow: Times


Name Value
hangup_time 1537982904356808
bridged_time 1537982892656807
created_time 1537982890176805
answered_time 1537982900476813
progress_time 0
transfer_time 0
last_hold_time 0
resurrect_time 0
hold_accum_time 0
progress_media_time 1537982892656807
profile_created_time 1537982890176805

OUR 10.31.200.2 SBC Dialing plan

Your Set CID is rewriting the number to the DID called. If you want the forwarded-to destination to see the number of the original caller, just take that out, i.e. route whatever goes to the Set CID to the Misc Destination instead.

However, some trunking providers prohibit sending a number that is not yours. I don’t know whether that applies to Neotel. If that’s your case, you could route forwarded calls via a different provider, or set up the system (as it is now) to send your company’s main number instead.

Otherwise, Neotel may require adding a Diversion header or putting the desired caller ID in P-Asserted-Identity or Remote-Party-ID. Another possibility is a format mismatch between the caller ID received from the original caller and what the provider expects for outgoing.

Finally, it appears that your SBC is looking for specific outbound caller_id_number values, which the original caller’s number presumably wouldn’t match, so you may also need a config change there.

Hi Stewart

Thanks very much for your reply.

Must i remove both sections of SETCID of CID name and CID number to blank ?

Our one sbc 10.31.200.3 allows all numbers to dial out but then routes the call to the sbc 10.31.200.2 that has the caller id of inbound number ‭0105010174‬ allocated to dial out to neotel/liqued telecom.

Our carrier allows us to dial any number as long as our sbc allows it.

The problem is don’t want all the client that call in to precent a new cid as a outbound call if i understand correcly the moment i remove the DID variable and that will also mean we have to open all numbers on (SBC/fusion pbx) to dial out ?

Hope i make sense or what of your suggestions will work for my scenario ?

Our SBC dial plans below in 2 steps :slight_smile:

  1. Below dial plan to dial out from freepbx

2.Below to dial plan take request from above SBC call request from freepbx to call out to Neotel on matching CID

So my theory is to remove the condition on option 2 SBC and will allow the divert to show callee CID for inbound and not the inbound DID ? Will this work ?

Hope to hear from you Thanks in advance

Sorry, I know nothing about your SBCs so can provide only general advice.

I believe that you are implementing a security function: if an external caller somehow gets into a DISA, caller-controlled transfer or other means of dialing an arbitrary external number, you want your SBC to block the call. However, you also want the ability to forward a call from any external caller to e.g. an employee’s mobile phone.

In principle, that should be easy. The SBC should permit the call if either the calling number is one belonging to your organization OR if the destination number is an authorized forwarding target.

Once you have done that, the default settings in FreePBX (which preserve the number of the original caller on Follow Me, Call Forward Unconditional and Misc Destination) should do what you want.

If you confirm that FreePBX is sending the INVITE to the SBC with the desired caller ID and destination number but the SBC is inappropriately blocking the call, you should seek help from a suitable forum or support group for the SBC.

Hi Stewart

Understand about the SBC but just want to confirm lastly with your remark below :

Yes we want to divert the inbound number 0105010174 to a mobile number 0634052391 but as mentioned, we can’t see the caller’s numbers it’s only showing the inbound number 0105010174. Must show various numbers that call into that number 0105010174‬ then divert to mobile 0634052391 but must show callers numbers on the mobile screen.

Will your suggestion of removing the CID name and number as print screen help with the above?

Yes, we have the number 0105010174 allowed to dial out from our SBC not sure if that is what you mean?

Which of those option should we use as we only have Misc Destination setup ? Must also setup Follow Me, Call Forward Unconditional?

Once i have confirmed from you what needs to be setup correcly on FreePBX then i can confirm if the invites are getting send correcly to SBC and what the SBC is doing with invites ?

Please confirm Thanks in advance ?

Thanks Stewart much appreciated

Johannes Victor

Why do you have the Set CID CallerID Number set to ${CDR(did)} ??!!! That is completely WRONG.

The CDR(did) is the number that was DIALED by the user (ie the outside caller). If you want the CALLLER’s CallerID you need to have ${CALLERID(num)}

Here’s the call coming into the system. You can see the CDR(did) var is set to the DESTINATION that was dialed. I.e. your inbound number.

Here’s the call jumping into the SetCID during the CallerID lookup process. As you can see here you are actively changing the CallerID number from 0315736200 to your OWN NUMBER based on the CDR(did) var you are using in Set CID.

FreePBX’s setup with extensions, outbound routes and trunks in NO WAY block the sending of the original callers CallerID when forwarded or sent back out a trunk/peer. YOU, as the user, have to go in and set all that and change settings to block that from happening.

Basically, you’re breaking something to get a result when that would be given with the “default” setup.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.