dolesec commented 5 months ago

FreePBX Version

FreePBX 17

Issue Description

im unable to pin down the update that triggered the issue however with any outbound call to the PSTN phones are now displaying 's' and i don't recall this during any testing last week and only noticed it today. this impacts all makes of phones...

note this entry in the attached log ... sip:s@fpbx17.cditcpbx.net

as well as the 's' displayed below the caller ID

examples of phone displays with this error in place on both S series and P series

Operating Environment

Relevant log output

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.250.170:5060;rport=9521;received=73.121.231.224;branch=z9hG4bKadcbffd
Call-ID: e96e90353f0c7b7@192.168.250.170
From: "1301" <sip:1301@fpbx17.cditcpbx.net>;tag=75221d971cc3420
To: <sip:4239722652@fpbx17.cditcpbx.net>;tag=30102018-c0f3-4740-a784-d45bb9c043ca
CSeq: 21 INVITE
Server: FPBX-17.0.15.27(21.0.2)
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REFER
Contact: <sip:45.79.206.42:5060>
P-Asserted-Identity: "CID:4236504818" <sip:s@fpbx17.cditcpbx.net>
Content-Type: application/sdp
Content-Length:   246

ramarajan222 commented 5 months ago

Hi @dolesec ,

We were unable to reproduce this is on our testing system, can you share the asterisk call trace with "pjsip set logger on " enabled?

dolesec commented 5 months ago

attached ....

call example.txt

ramarajan222 commented 5 months ago

Hi @dolesec Please enable "Trust RPID/PAI" on the PJSIP trunk advanced setting and give it a try .

dolesec commented 5 months ago

@ramarajan222

that was already enabled during testing ...

I've applied all updates this morning and tested once more with the same result

kguptasangoma commented 5 months ago

Hey @dolesec we are unable to reproduce the issue locally.

Is it possible for you to open support ticket against any commercial module and allow us to ssh to your system to debug further? thanks

blazestudios97 commented 5 months ago

You guys do realize the unable to reproduce the problem isn't even reproducing the proper response to begin with? @dolesec's issue is with the CONNECTEDLINE() being sent back to the device. If you are getting proper CONNECTEDLINE() back then the CNAM portion of the CONNECTEDLINE() should have "CID: outbound CID num" so in @dolesec case it was "CID:4236504818", however, in the testing showed by Sangoma to replicate the issue there's no CONNECTEDLINE() details in their display.

-- Executing [s@macro-dialout-trunk:31] ExecIf("PJSIP/1103-00000006", "1?Set(CONNECTEDLINE(num,i)=13243866*14239722652)") in new stack
-- Executing [s@macro-dialout-trunk:32] ExecIf("PJSIP/1103-00000006", "1?Set(CONNECTEDLINE(name,i)=CID:4236504818)") in new stack

This should result in the CONNECTEDLINE() name being "CID:4236504818" and the CONNECTEDLINE() number being "13243866*14239722652" which is not happening. I guess some of the confusion is from @dolesec not posting the entire SIP message (I'll skip the SDP body)

SIP/2.0 183 Session Progress
Via: SIP/2.0/TLS 73.121.231.224:35179;rport=35179;received=73.121.231.224;branch=z9hG4bKPjr95E-3E4XbbBsCk5-uhJPB4GvaRX0asD;alias
Call-ID: 1GgvQMxjvOz1DsNV4RN41oFbXxs77SLb
From: <sip:1103@fpbx17.cditcpbx.net>;tag=e1J.C3tOLA4VMbXQJG3z26HT0S4HS0W9
To: <sip:4239722652@fpbx17.cditcpbx.net>;tag=c2af043d-eb1c-4c23-add3-60a19fe4c809
CSeq: 31430 INVITE
Server: FPBX-17.0.15.27(21.0.2)
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REFER
Contact: <sip:45.79.206.42:5061;transport=TLS>
P-Asserted-Identity: "CID:4236504818" <sip:s@fpbx17.cditcpbx.net>
Content-Type: application/sdp
Content-Length:   344

Just to make sure everyone is on the same page, this is a CONNECTEDLINE() issue not an Outbound CallerID issue and the data shown as part of trying to reproduce the issue isn't even showing CONNECTEDLINE() details, correct or not.

dolesec commented 5 months ago

@blazestudios97 I was thinking about 'connected line' being connected to the issue but was unsure of the operation. thanks for taking a look at this and commenting

blazestudios97 commented 5 months ago

Yeah, you're not getting back proper CONNECTEDLINE() for some reason and it ends up using the "FROM" user, which in this case is 's' since that the extension you're in. I'm a little curious as to why it's not using the proper value. Can you try this with a provider that doesn't have a prefix prepended to the destination? Or change the Flowroute config to use registration so you're not having to prepend the tech prefix?

dolesec commented 5 months ago

@blazestudios97 I can and I'll report back later today.

the method with the prefix is in place on every other system I have using FreePBX 16... fwiw I don't recall seeing this issue on those systems; I'll connect a device to one of those 16 systems as well and confirm.

thank you for the assist :)

dolesec commented 5 months ago

@ramarajan222 @kguptasangoma changing the trunk to registration and not using a prefix results in the same issue.

full call log with pjsip set logger on attached ... call example - freepbx17 - registration - no prefix.txt

thanks @blazestudios97 for getting us pointed in the right direction!

dolesec commented 5 months ago

@ramarajan222 @kguptasangoma I was also able to confirm this issue does not exist in freepbx 16 using the trunk's original configuration with IP based auth and the prefix ... the issue is definitely introduced with Freepbx17; I had only been testing with Sipstation trunks and only recently moved to flowroute for testing when i lost access to those.

freepbx 16 connected line working.txt

trunk GUI config that's working in 16 ...

samthecrazyman commented 5 months ago

Hi there

I seem to be having the same issue. My FreePBX 16 died for some reason recently so I thought I'd give the FreePBX 17 setup a go. I have Mitel phones setup in SIP mode and these seem to be having the same issue. When you dial a number out to the PSTN, they say 'Ringing s' rather than 'Ringing 07...'. This used to be fine on 16, I have only just freshly installed FreePBX 17. If I can be any help tracking this down, please let me know.

kguptasangoma commented 5 months ago

Hi @samthecrazyman Can you please share your pjsip trunk configuration screenshot ?

samthecrazyman commented 5 months ago

Hi, sure, here you go.

blazestudios97 commented 5 months ago

@dolesec Can you please show the actual configs for the extension and the trunk endpoints being used. The actual config as written out in .conf files not what the GUI shows.

blazestudios97 commented 5 months ago

Well in my testing I found another issue with connectedline. When you go to create a trunk in the GUI it says that "Send Connected Line" is disabled by default, however, when the config is generated it is missing send_connected_line=no with out that in the config to expressly turn off that feature, it's enabled by default in Asterisk. So the GUI tells the user it is disabled and enabling it can cause problems with the providers, however, it is enabled when the config is generated.

dolesec commented 5 months ago

@blazestudios97 ... everything but pjsip.auth

1102 is the extension my recent tests are originating from using the flowroute registration trunk without the prefix as you suggested yesterday... results are the same however whether using registration or IP auth with the prefix

Archive.zip

https://github.com/FreePBX/issue-tracker/assets/2153999/a17049cd-50e3-4703-ab26-a81fe9da8f92

blazestudios97 commented 5 months ago

@dolesec Try this, go into the pjsip.endpoint.conf file and add this to the Flowroute endpoint:

send_connected_line=no
trust_connected_line=no

Then just do asterisk -rx "module reload res_pjsip.so" to reload pjsip and test from there.

dolesec commented 5 months ago

@blazestudios97 - done ... same result - i see the 's' for connected line displayed on the handset

[Flowroute_registration]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn-e164-us
disallow=all
allow=g722,ulaw
aors=Flowroute_registration
rtp_keepalive=0
language=en
outbound_auth=Flowroute_registration
user_eq_phone=no
t38_udptl=yes
t38_udptl_ec=redundancy
fax_detect=yes
trust_id_inbound=yes
t38_udptl_nat=no
send_rpid=yes
send_pai=yes
direct_media=no
rtp_symmetric=yes
dtmf_mode=auto
send_connected_line=no
trust_connected_line=no

blazestudios97 commented 5 months ago

@dolesec Can we get a new trace again?

dolesec commented 5 months ago

@blazestudios97 - attached

new call trace.txt

blazestudios97 commented 5 months ago

@dolesec Can you modify the dialplan in macro-dialout-trunk and after the CONNECTEDLINE() settings add a DumpChan to it? Let's see what the CONNECTEDLINE() on the channel is.

dolesec commented 5 months ago

will do @blazestudios97 , also tested from yealink t46s with same results -- thats where i initially noted the problem; i then moved to sangoma p series to see if it was vendor dependent and the issue persisted with the sangoma endpoint.

dolesec commented 5 months ago

@blazestudios97 - can I get more guidance on how to add what you are asking for please

from my extensions_additional ...

[macro-dialout-trunk]
include => macro-dialout-trunk-custom
exten => s,1,Set(DIAL_TRUNK=${ARG1})
exten => s,n,ExecIf($["${DIRECTION}" = "INBOUND"]?Set(DIAL_OPTIONS=${STRREPLACE(DIAL_OPTIONS,T)}))
exten => s,n,ExecIf($["${QCALLBACK}" = "1"]?Set(DIAL_OPTIONS=${STRREPLACE(DIAL_OPTIONS,t)}))
exten => s,n,ExecIf($["${QCALLBACK}" = "1"]?Set(DIAL_OPTIONS=${STRREPLACE(DIAL_OPTIONS,T)}))
exten => s,n,GosubIf($[$["${ARG3}" != ""] & $["${DB(AMPUSER/${AMPUSER}/pinless)}" != "NOPASSWD"]]?sub-pincheck,s,1(${ARG3}))
exten => s,n,ExecIf($["${INTRACOMPANYROUTE}" = "YES" & ${DB_EXISTS(AMPUSER/${AMPUSER}/cidnum)} & "${AMPUSER}" != "${DB(AMPUSER/${AMPUSER}/cidnum)}"]?Set(CALLERID(num)=${DB(AMPUSER/${AMPUSER}/cidnum)}))
exten => s,n,GotoIf($["x${OUTDISABLE_${DIAL_TRUNK}}" = "xon"]?disabletrunk,1)
exten => s,n,Set(DIAL_NUMBER=${ARG2})
exten => s,n,Set(DIAL_TRUNK_OPTIONS=${DIAL_OPTIONS})
exten => s,n,Set(OUTBOUND_GROUP=OUT_${DIAL_TRUNK})
exten => s,n,Set(DIAL_TRUNK_OPTIONS=${IF($["${DB_EXISTS(TRUNK/${DIAL_TRUNK}/dialopts)}" = "1"]?${DB_RESULT}:${TRUNK_OPTIONS})})
exten => s,n,ExecIf($["${QCALLBACK}" = "1"]?Set(DIAL_TRUNK_OPTIONS=${STRREPLACE(DIAL_TRUNK_OPTIONS,T)}))
exten => s,n,GotoIf($["${OUTMAXCHANS_${DIAL_TRUNK}}" = ""]?nomax)
exten => s,n,GotoIf($[ ${GROUP_COUNT(OUT_${DIAL_TRUNK})} >= ${OUTMAXCHANS_${DIAL_TRUNK}} ]?chanfull)
exten => s,n(nomax),GotoIf($["${INTRACOMPANYROUTE}" = "YES"]?skipoutcid)
exten => s,n,Gosub(macro-outbound-callerid,s,1(${DIAL_TRUNK}))
exten => s,n(skipoutcid),GosubIf($["${PREFIX_TRUNK_${DIAL_TRUNK}}" != ""]?sub-flp-${DIAL_TRUNK},s,1())
exten => s,n,Set(OUTNUM=${OUTPREFIX_${DIAL_TRUNK}}${DIAL_NUMBER})
exten => s,n,Set(custom=${CUT(OUT_${DIAL_TRUNK},:,1)})
exten => s,n,ExecIf($["${MOHCLASS}"!="default" & "${MOHCLASS}"!="" & "${FORCE_CONFIRM}"="" ]?Set(DIAL_TRUNK_MOH=${MOHCLASS}))
exten => s,n,ExecIf($["${FORCE_CONFIRM}"!="" ]?Set(DIAL_TRUNK_OPTIONS=${DIAL_TRUNK_OPTIONS}U(macro-confirm)))
exten => s,n(gocall),Gosub(macro-dialout-trunk-predial-hook,s,1())
exten => s,n,GotoIf($["${CRM_DIRECTION}"!=""]?skipcrm)
exten => s,n,Set(__CRM_DIRECTION=OUTBOUND)
exten => s,n,Set(__CRM_DESTINATION=${OUTNUM})
exten => s,n,Set(__CRM_SOURCE=${AMPUSER})
exten => s,n,AGI(agi://127.0.0.1/sangomacrm.agi)
exten => s,n,Set(CHANNEL(hangup_handler_push)=crm-hangup,s,1)
exten => s,n(skipcrm),Noop(CRM Finished)
exten => s,n,GotoIf($["${PREDIAL_HOOK_RET}" = "BYPASS"]?bypass,1)
exten => s,n,ExecIf($["${DB(AMPUSER/${AMPUSER}/cidname)}" != ""]?Set(CONNECTEDLINE(num,i)=${DIAL_NUMBER}))
exten => s,n,ExecIf($[$["${DB(AMPUSER/${AMPUSER}/cidname)}" != ""] & $["${CALLERID(name)}"!="hidden"]]?Set(CONNECTEDLINE(name,i)=CID:${CALLERID(number)}))
exten => s,n,ExecIf($[$["${DB(AMPUSER/${AMPUSER}/cidname)}" != ""] & $["${CALLERID(name)}"="hidden"]]?Set(CONNECTEDLINE(name,i)=CID:(Hidden)${CALLERID(number)}))
exten => s,n,GotoIf($["${custom}" = "AMP"]?customtrunk)
exten => s,n,ExecIf($["${DIRECTION}" = "INBOUND"]?Set(DIAL_TRUNK_OPTIONS=${STRREPLACE(DIAL_TRUNK_OPTIONS,T)}))
exten => s,n,Set(HASH(__SIPHEADERS,Alert-Info)=unset)
exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM}${OUT_${DIAL_TRUNK}_SUFFIX},${TRUNK_RING_TIMER},${DIAL_TRUNK_OPTIONS}b(func-apply-sipheaders^s^1,(${DIAL_TRUNK}))U(sub-send-obroute-email^${DIAL_NUMBER}^${MACRO_EXTEN}^${DIAL_TRUNK}^${NOW}^${CALLERID(name)}^${CALLERID(number)},^${DIAL_TRUNK_MOH}))
exten => s,n,Noop(Dial failed for some reason with DIALSTATUS = ${DIALSTATUS} and HANGUPCAUSE = ${HANGUPCAUSE})
exten => s,n,GotoIf($["${ARG4}" = "on"]?continue,1:s-${DIALSTATUS},1)
exten => s,n(customtrunk),Set(pre_num=${CUT(OUT_${DIAL_TRUNK},$,1)})
exten => s,n,Set(the_num=${CUT(OUT_${DIAL_TRUNK},$,2)})
exten => s,n,Set(post_num=${CUT(OUT_${DIAL_TRUNK},$,3)})
exten => s,n,GotoIf($["${the_num}" = "OUTNUM"]?outnum:skipoutnum)
exten => s,n(outnum),Set(the_num=${OUTNUM})
exten => s,n(skipoutnum),Dial(${pre_num:4}${the_num}${post_num},${TRUNK_RING_TIMER},${DIAL_TRUNK_OPTIONS})
exten => s,n,Noop(Dial failed for some reason with DIALSTATUS = ${DIALSTATUS} and HANGUPCAUSE = ${HANGUPCAUSE})
exten => s,n,GotoIf($["${ARG4}" = "on"]?continue,1:s-${DIALSTATUS},1)
exten => s,n(chanfull),Noop(max channels used up)

exten => s-BUSY,1,Noop(Dial failed due to trunk reporting BUSY - giving up)
exten => s-BUSY,n,Playtones(busy)
exten => s-BUSY,n,Busy(20)

exten => s-ANSWER,1,Noop(Call successfully answered - Hanging up now)
exten => s-ANSWER,n,Gosub(macro-hangupcall,s,1())

exten => s-NOANSWER,1,Noop(Dial failed due to trunk reporting NOANSWER - giving up)
exten => s-NOANSWER,n,Progress
exten => s-NOANSWER,n,Playback(number-not-answering,noanswer)
exten => s-NOANSWER,n,Congestion(20)

exten => s-INVALIDNMBR,1,Noop(Dial failed due to trunk reporting Address Incomplete - giving up)
exten => s-INVALIDNMBR,n,Progress
exten => s-INVALIDNMBR,n,Playback(ss-noservice,noanswer)
exten => s-INVALIDNMBR,n,Busy(20)

exten => s-CHANGED,1,Noop(Dial failed due to trunk reporting Number Changed - giving up)
exten => s-CHANGED,n,Playtones(busy)
exten => s-CHANGED,n,Busy(20)

exten => _s-.,1,Set(RC=${IF($[${ISNULL(${HANGUPCAUSE})}]?0:${HANGUPCAUSE})})
exten => _s-.,n,Goto(${RC},1)

exten => 17,1,Goto(s-BUSY,1)

exten => 18,1,Goto(s-NOANSWER,1)

exten => 22,1,Goto(s-CHANGED,1)

exten => 23,1,Goto(s-CHANGED,1)

exten => 1,1,Goto(s-INVALIDNMBR,1)

exten => 28,1,Goto(s-INVALIDNMBR,1)

exten => _X,1,Goto(continue,1)

exten => _X.,1,Goto(continue,1)

exten => continue,1(noreport),Noop(TRUNK Dial failed due to ${DIALSTATUS} HANGUPCAUSE: ${HANGUPCAUSE} - failing through to other trunks)
exten => continue,n,ExecIf($["${AMPUSER}"!="" ]?Set(CALLERID(number)=${AMPUSER}))

exten => disabletrunk,1,Noop(TRUNK: ${OUT_${DIAL_TRUNK}} DISABLED - falling through to next trunk)

exten => bypass,1,Noop(TRUNK: ${OUT_${DIAL_TRUNK}} BYPASSING because dialout-trunk-predial-hook)

exten => h,1,Gosub(macro-hangupcall,s,1())

;--== end of [macro-dialout-trunk] ==--;

blazestudios97 commented 5 months ago

@dolesec Can you also attempt this on v21 and v18? While v21 is a six month old version it's still more current than the year old version of Asterisk v20 FreePBX installs. While v18 is the current release from May 2024. Either one of those might have a different result as there might have been a bug or issue that was corrected with more current releases.

As for the dialplan make this change. I added a line space around there line to be added.

exten => s,n,ExecIf($[$["${DB(AMPUSER/${AMPUSER}/cidname)}" != ""] & $["${CALLERID(name)}"!="hidden"]]?Set(CONNECTEDLINE(name,i)=CID:${CALLERID(number)}))
exten => s,n,ExecIf($[$["${DB(AMPUSER/${AMPUSER}/cidname)}" != ""] & $["${CALLERID(name)}"="hidden"]]?Set(CONNECTEDLINE(name,i)=CID:(Hidden)${CALLERID(number)}))

exten => s,n,DumpChan ; add this here

exten => s,n,GotoIf($["${custom}" = "AMP"]?customtrunk)

dolesec commented 5 months ago

@blazestudios97 - here it is... I sincerely appreciate your time and effort on this one

let me know if got it right

call trace - asterisk 21 - dump chan.txt

as an aside, I did hear back from Kapil and Ram with the following ...

The 183 response from the telco is different for working and non-working calls.

Working call (626-565-0753) has the PAI header.
Non-working call (423-972-2652) does not have the PAI header.

working
<--- Received SIP response (790 bytes) from UDP:[34.226.36.34:5060](http://34.226.36.34:5060/) --->
SIP/2.0 183 Session Progress
From: <[sip:4236504818@45.79.206.42](mailto:sip%3A4236504818@45.79.206.42)>;tag=053c557a-22c8-4d9b-b4dd-90e5b656cacc
To: <[sip:16265650753@us-east-va.sip.flowroute.com](mailto:sip%3A16265650753@us-east-va.sip.flowroute.com)>;tag=gK00d84867
Via: SIP/2.0/UDP 45.79.206.42:5060;received=45.79.206.42;rport=5060;branch=z9hG4bKPj6746b7c9-b1ff-4070-8ea6-e2a3a33be090
Call-ID: d9154aeb-961b-49f3-aa9d-5b598426d365
CSeq: 15117 INVITE
Record-Route: <sip:52.55.87.5:5060;lr>
Record-Route: <sip:34.226.36.34:5060;lr>
Contact: <[sip:+16265650753@67.231.4.85:5060](http://sip:+16265650753@67.231.4.85:5060/)>
P-Asserted-Identity: "+16265650753" <[sip:+16265650753@52.55.87.5](mailto:sip%3A%2B16265650753@52.55.87.5)>
Content-Length:   175
Content-Type: application/sdp

Not working 
<--- Received SIP response (728 bytes) from UDP:[34.226.36.34:5060](http://34.226.36.34:5060/) --->
SIP/2.0 183 Session Progress
From: <[sip:4236504818@45.79.206.42](mailto:sip%3A4236504818@45.79.206.42)>;tag=c6b07738-ab22-49bb-a617-4ae59ffa397e
To: <[sip:14239722652@us-east-va.sip.flowroute.com](mailto:sip%3A14239722652@us-east-va.sip.flowroute.com)>;tag=gK00e106a9
Via: SIP/2.0/UDP 45.79.206.42:5060;received=45.79.206.42;rport=5060;branch=z9hG4bKPjc1c0e816-9fa5-47d6-8de4-a78c31024291
Call-ID: fd08d2bb-0a75-421a-8569-904e7cd942aa
CSeq: 22702 INVITE
Record-Route: <sip:35.173.172.171:5060;lr>
Record-Route: <sip:34.226.36.34:5060;lr>
Contact: <[sip:+14239722652@67.231.4.85:5060](http://sip:+14239722652@67.231.4.85:5060/)>
Content-Length:   176
Content-Type: application/sdp

I'm certainly in the deep end over my head on this one and my only comment back to them was this works on 16 with the same provider...

blazestudios97 commented 5 months ago

I don't think that call trace is correct. It doesn't have any dumpchan information and it still shows Asterisk 20.4.0 as the Asterisk version.

dolesec commented 5 months ago

i had only done the reload you specified earlier @blazestudios97 , i think that was my mistake -- i have a meeting at 11am and will update this after that call -- ty sir

dolesec commented 5 months ago

ok - i see it looks correct now , sorry about the mis-step @blazestudios97

see attached

corercted call trace with dump.txt

dolesec commented 5 months ago

this looks promising ... endpoint however is still showing the 's'

Dumping Info For Channel: PJSIP/1102-00000002:

Info: Name= PJSIP/1102-00000002 Type= PJSIP UniqueID= 1718813422.16 LinkedID= 1718813422.16 CallerIDNum= 4236504818 CallerIDName= (N/A) ConnectedLineIDNum= 14239722652 ConnectedLineIDName=CID:4236504818 DNIDDigits= 4239722652 ...

blazestudios97 commented 5 months ago

@dolesec Can you do a version switch to 21 and test?

dolesec commented 5 months ago

@blazestudios97 that test was on 21 ...

Asterisk 21.0.2

blazestudios97 commented 5 months ago

@dolesec OK I was just thrown by the User Agent in the trace.

User-Agent: FPBX-17.0.15.27(20.4.0)

So it looks like the user agent setting in the global settings of pjsip.conf aren't being updated when the Asterisk version changes.

dolesec commented 5 months ago

so @blazestudios97, what does the dump indicate to you?

based on what I see in the channel dump things appear to be in order at that level

kguptasangoma commented 5 months ago

just fyi - 17 latest core module has got the fixes to set the send_connected_line parameter properly via GUI. Also its setting to FALSE by default (on fresh system).

chewy-chewbacca commented 5 months ago

I can confirm that the issue persists when asterisk-version-switch (ing) to 18

dolesec commented 5 months ago

@chewy-chewbacca - The issue still exists in general, last I spoke with @kguptasangoma it was still under investigation

chewy-chewbacca commented 5 months ago

A temporary workaround per Kapil / @kguptasangoma at the community, which I verified works is:

Set Trust RPID =NO and Send Connected Line=NO on your extension’s PJSIP advanced settings.

https://community.freepbx.org/t/freepbx-17-outbound-caller-id-shows-s/97292/3

jissphilip commented 4 months ago

core version 17.0.9.76

FreePBX / issue-tracker

[bug]: connected line / asserted identify displays 's' #264

FreePBX Version

Issue Description

Operating Environment

Relevant log output

Dumping Info For Channel: PJSIP/1102-00000002: