Caller ID issues in Dynamic Routes

I’m having an issue with dynamic routes. I am trying to sort a call by its caller ID name, which contains the dialed number when it rings, and on both logs, the CDR and the console logs. The only thing I could think is happening is somehow it is getting the dialed number and changing when it is ringing as the dynamic route which tries to match $["${CALLERID(name)}"="0xxxxxxxxx"]" does not work. If you can think of any way to solve this it would be greatly appreciated.

Thank you,
Matthew

Turns out that it would be beneficial to filter based on this part of the From header

From: "this bit"

If anyone can now help me find a way to filter based on this bit I would be very appreciative.

${SIP_HEADER(From)}

Asterisk cmd Set - VoIP-Info

Asterisk func sip_header: Description and Examples - VoIP-Info

Removing Characters from String in Bash (linuxhint.com)

Asterisk cmd System - VoIP-Info

1 Like

Should I use PJSIP header instead or should I use SIP

You would use whatever trunk type you have.

1 Like

This doesn’t work for some reason - could be that the From header contains bits outside of the “”, or it could be that the PJSIP_HEADER function isn’t returning data - which seems to have happened when I tried to put it in as a context.

Are you using Asterisk 18 Function_PJSIP_HEADER - Asterisk Project - Asterisk Project Wiki

exten => 1,1,Set(somevar=${PJSIP_HEADER(read,From)})

1 Like

From must contain a URI, and a tag parameter, and the bit in quotes is never the URI. The display name doesn’t always have to be in quotes, and if it is a pure number, that is one of the cases where quotes are optional.

You haven’t provided either the actual From header, or the code you are now using to parse it.

I’m pretty sure you can do all the necessary parsing without shelling out.

Using the From display name for the called number is a strange abuse of this field.

1 Like

The user is reaching out for help here, right? A good time to provide an alternative to accompany your feedback.

1 Like

Yep that’s the way I’m using it currently - I came up with a parser to cut it out of the string
$["${CUT(CUT(PJSIP_HEADER(read, From), ", 2), ", 1)}"="0xxxxxxxxxx"]

The From Header comes through as
From: "0xxxxxxxxxx" <sip:[email protected]>;tag=as5c1f4d6

I believe the CUTs should take it out of the string, but for some reason beyond me it doesn’t work.

If you just run ${PJSIP_HEADER(read,From)} does it populate as expected?

1 Like

I recommend baby steps, ‘noop’ the result after each ‘CUT’

1 Like

I have a log that says
[2023-07-15 01:58:35] VERBOSE[311155][C-00000a2b] pbx.c: Executing [3385315e1@fixcallerid:1] Verbose("PJSIP/Sipgate-xxx-000000a4", "Trying to set ") in new stack that is sent out by this line in the context - exten => _X!,1,Verbose(Trying to set ${PJSIP_HEADER(read, From)})

Unless the context requires me to restart FreePBX instead of just reloading the config, I am unsure what is going on with that.

If one strange thing is being done, others may be as well; to help properly people need to see the whole picture (in this case, starting from a complete INVITE request). Also, if something strange is being done, it is better to remove it at source, including. possibly by changing the source.

At the moment, this looks like a case where the detail is being addressed when the overall goal should be addressed.

1 Like

What version of Asterisk are you using?

1 Like

I am using Asterisk 17.9.3.

The entire invite request is looking like

INVITE sip:accountid@ip:5060 SIP/2.0	
Record-Route: <sip:217.10.79.23;lr>	
Record-Route: <sip:172.20.40.8;lr>	
Record-Route: <sip:217.10.68.137;lr>	
Via: SIP/2.0/UDP 217.10.79.23;branch=z9hG4bK9dd8.6d54634dbc5d41638a82dc416f013f5e.0	
Via: SIP/2.0/UDP 172.20.40.8;branch=z9hG4bK9dd8.38578b2ed270fbed36c66b1f039d132a.0	
Via: SIP/2.0/UDP 217.10.68.137;branch=z9hG4bK9dd8.b93e2dc429b5a2a55200a97ee0fd6293.0	
Via: SIP/2.0/UDP 212.9.44.194:5060;branch=z9hG4bK00dd4e2a	
Max-Forwards: 67	
From: "called" <sip:[email protected]>;tag=as61dfcac9	
To: <sip:[email protected]>	
Contact: <sip:[email protected]:5060>	
Call-ID: [email protected]	
CSeq: 103 INVITE	
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE	
Supported: replaces	
Content-Type: application/sdp	
Content-Length: 435	
		
v=0	
o=root 95277605 95277606 IN IP4 212.9.44.178	
s=sipgate VoIP GW	
c=IN IP4 212.9.44.178	
t=0 0	
m=audio 15302 RTP/AVP 9 8 0 3 97 18 112 101	
a=rtpmap:9 G722/8000	
a=rtpmap:8 PCMA/8000	
a=rtpmap:0 PCMU/8000	
a=rtpmap:3 GSM/8000	
a=rtpmap:97 iLBC/8000	
a=fmtp:97 mode=30	
a=rtpmap:18 G729/8000	
a=fmtp:18 annexb=no	
a=rtpmap:112 G726-32/8000	
a=rtpmap:101 telephone-event/8000	
a=fmtp:101 0-16	
a=sendrecv	
a=rtcp:15303	
a=ptime:20

I am looking for a solution to filter calls by the called number to then send it to different extensions.
Sorry for the late response, I was on holiday.

I’d suggest you ask sipgate to configure their system to work according to their documentation:

which wouldn’t require any jiggery-pokery, at all. On the other hand, the fact that there is a , two hop, web link loop on the click here for general instructions doesn’t bode well.

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