Extensions_custom.conf File issue

FreePBX Providers
, , , ,
1

Hello everyone,

I was hoping to get some assistance regarding a problem I am experiencing with the context on a trunk set up for inbound calls.

Some time ago, I reached out to the community for help in setting up Twilio, as their trunk dropped the international standard dialling code presentation for a shorter version. I followed the recommendation to make the necessary changes in the context file for the extension, and it has been working perfectly ever since.

However, I am now faced with a new predicament, I am looking to introduce a new service provider called SignalWire, who is requesting that the context be changed to “from-signalwire”. This is where the problem arises: if I make changes to incorporate this, my Twilio setup stops functioning. Is there any way to add this to the original setup to allow both services to work harmoniously? I would greatly appreciate any assistance, as I am not entirely sure how to modify this correctly without causing any issues.

I almost forgot to mention that the current context for Twilio is “from-Twilio-processing”. Somehow, I need to include this for the new trunk context for SignalWire like this from-signalwire.
I only hope that I have explained this in such a way that it makes sense. If not, please let me know and I can link my original post for the Twilio set-up.
Once again, I am sincerely grateful for any help or insights that can shed light on this particular scenario.

2

Context names have no effect on the remote party. Their examples may use that context, but they are only examples.

If you need a custom context for them, it should only be included in the trunk definitions for them, so should not affect other trunks.

3

Hello @david55,
I am truly grateful for your reply.
I have generated a printout of the information found in the logs below. This is why I posed the question in the specific format that I did, as I initially believed it was the source of the problem. However, it seems that I may have misunderstood the situation. While I am not a full-time coder for free PBX environment in question, I do possess enough programming knowledge to handle basic functions and operations on a system. Unfortunately, I am not as proficient in the more complex aspects, such as what this particular issue entails. I am hopeful that by sharing the printout below with you, it may shed some light on the matter. I would greatly appreciate any assistance you can provide.

res_pjsip_session.c: signalwire: Call (UDP: ip :5060) to extension ‘s’ rejected because extension not found in context ‘from-signalwire’.

I have added some additional details from the logs to hopefully help Shane a wee bit more light call the DID is in the system and also set as an inbound extension for testing.

0570[2023-10-31 15:37:16] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:1] NoOp(“PJSIP/signalwire-0000007d”, “No DID or CID Match”) in new stack

10571[2023-10-31 15:37:16] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:2] Answer(“PJSIP/signalwire-0000007d”, “”) in new stack

10572[2023-10-31 15:37:16] VERBOSE[12788] res_srtp.c: Unsupported crypto suite: AES_256_CM_HMAC_SHA1_80

10573[2023-10-31 15:37:17] WARNING[24181][C-00000054] chan_sip.c: This function can only be used on SIP channels.

10574[2023-10-31 15:37:17] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:3] Log(“PJSIP/signalwire-0000007d”, "WARNING,Friendly Scanner from ") in new stack

10575[2023-10-31 15:37:17] WARNING[24181][C-00000054] Ext. s: Friendly Scanner from

10576[2023-10-31 15:37:17] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:4] Wait(“PJSIP/signalwire-0000007d”, “2”) in new stack

10577[2023-10-31 15:37:19] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:5] Playback(“PJSIP/signalwire-0000007d”, “ss-noservice”) in new stack

10578[2023-10-31 15:37:19] VERBOSE[24181][C-00000054] file.c: <PJSIP/signalwire-0000007d> Playing ‘ss-noservice.ulaw’ (language ‘en_NZ’)

10579[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:6] SayAlpha(“PJSIP/signalwire-0000007d”, “”) in new stack

10580[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@from-pstn:7] Hangup(“PJSIP/signalwire-0000007d”, “”) in new stack

10581[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Spawn extension (from-pstn, s, 7) exited non-zero on ‘PJSIP/signalwire-0000007d’

10582[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [h@from-pstn:1] Macro(“PJSIP/signalwire-0000007d”, “hangupcall,”) in new stack

10583[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@macro-hangupcall:1] Set(“PJSIP/signalwire-0000007d”, “__MCVMSTATUS=”) in new stack

10584[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@macro-hangupcall:2] Gosub(“PJSIP/signalwire-0000007d”, “app-missedcall-hangup,s,1()”) in new stack

10585[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:1] NoOp(“PJSIP/signalwire-0000007d”, “Dialed: s”) in new stack

10586[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:2] NoOp(“PJSIP/signalwire-0000007d”, "Caller: ") in new stack

10587[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:3] GotoIf(“PJSIP/signalwire-0000007d”, “0?exit”) in new stack

10588[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:4] Set(“PJSIP/signalwire-0000007d”, “EXTENNUM=s”) in new stack

10589[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:5] Set(“PJSIP/signalwire-0000007d”, “FEXTENNUM=s”) in new stack

10590[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:6] GotoIf(“PJSIP/signalwire-0000007d”, “0?exit”) in new stack

10591[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:7] AGI(“PJSIP/signalwire-0000007d”, “agi://127.0.0.1/missedcallnotify.php,s,s,0,PJSIP/signalwire-0000007d,”) in new stack

10592[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] res_agi.c: <PJSIP/signalwire-0000007d>AGI Script agi://127.0.0.1/missedcallnotify.php completed, returning 0

10593[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@app-missedcall-hangup:8] Return(“PJSIP/signalwire-0000007d”, “”) in new stack

10594[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@macro-hangupcall:3] GotoIf(“PJSIP/signalwire-0000007d”, “1?theend”) in new stack

10595[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx_builtins.c: Goto (macro-hangupcall,s,5)

10596[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@macro-hangupcall:5] ExecIf(“PJSIP/signalwire-0000007d”, “0?Set(CDR(recordingfile)=)”) in new stack

10597[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Executing [s@macro-hangupcall:6] Hangup(“PJSIP/signalwire-0000007d”, “”) in new stack

10598[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] app_macro.c: Spawn extension (macro-hangupcall, s, 6) exited non-zero on ‘PJSIP/signalwire-0000007d’ in macro ‘hangupcall’

10599[2023-10-31 15:37:23] VERBOSE[24181][C-00000054] pbx.c: Spawn extension (from-pstn, h, 1) exited non-zero on ‘PJSIP/signalwire-0000007d’

4

Sounds like something is not setup correctly. You are calling extension s in the from-singalwire context, which it doesn’t have. You might need to consult with the vendor to determine if the context is the issue, or if you have a misconfiguration somewhere.

@david55 is right, since you’re using different contexts, there shouldn’t be a FreePBX conflict.

5

Hi @comtech thank you for your reply, that is what I have been racking my brain around. I have followed the set up guide to the T but it leads back to the original question which I think I may be picking up wrong and also leading to @david55’s answer.

The link below shows and states that you must clearly change the context, but if I do that it leads me back to the same original statement it breaks the first part of the system that works. If you look at this, they clearly howto set free PBX up in it, but indicate the context must be changed

6

I have a system with a SignalWire trunk. An incoming INVITE looks like this:

INVITE sip:[email protected]:5061;transport=TLS;line=zfcwzgn SIP/2.0
...
From: <sip:[email protected]>;tag=34ct9aQNyaUBH
To: <sip:[email protected]>
...

If you have only one number on the SignalWire trunk, you can set Contact User to your DID number (in whatever format you like) and that number will appear in the URI (instead of s) and will match an Inbound Route specifying that DID. In that case, you can leave the Context field for the trunk blank (it will use from-trunk or from-pstn, which do the same thing).

If you have multiple numbers on the trunk, you can set Context to from-pstn-toheader, which in this case would use +14012345678 as the DID; an Inbound Route with DID Number set to +14012345678 would be matched.

If for some reason you need the incoming number to be in a different format, you could copy the from-pstn-toheader context to extensions_custom.conf, modify it to put the called number in the desired format, and name it from-signalwire.

7

@Stewart1, I would like to express my utmost gratitude for your outstanding support in resolving the issue with the caller ID conversion from the PSTN to the header. Your expertise and dedication within the free PBX community are truly commendable. This solution has saved me an extensive amount of time that would have otherwise been spent searching for a seemingly obvious answer.

Regrettably, I am unable to devote as much time as I would like to fully immerse myself in training and mastering the intricacies of the system. Nonetheless, I find it invigorating to expand my knowledge through engaging with new technologies such as this one. Surprisingly, I have been using this system for over a decade, and one would assume that I would be familiar with something as simple as this. However, since this is not my primary occupation, it does not receive the attention it truly deserves.
Once again, I sincerely appreciate your assistance in resolving this matter.

Ps I used ( from-pstn-toheader ) worked a treat

1 Like
8

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