Number redirect

firsttechvoip · September 26, 2018, 6:23pm

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

Stewart1 · September 26, 2018, 7:27pm

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.

firsttechvoip · September 26, 2018, 8:58pm

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

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

Stewart1 · September 26, 2018, 9:55pm

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.

firsttechvoip · September 27, 2018, 6:03am

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

BlazeStudios · September 27, 2018, 1:07pm

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.

system · October 4, 2018, 1:07pm

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