What did you try and what happened?
A good thing to lead with.
Using a package like FreePBX or Vicidial can change the solution.
People who know GUI may be different than people who don’t.
GUIs may clobber configuration files and require different solutions.
On Monday 08 April 2024 at 18:57:02, asterisknooob via Asterisk Community
wrote:
I am using Vicidial Btw.
I thought that was a pre-configured system complete with dialplans, which
happens to be based on Asterisk, and provides a GUI for managing how those
dialplans work.
Maybe I’m wrong, but if not, then I think asking here how to write your own
Asterisk dialplans is not the right way of using Vicidial.
Antony.
–
1960s: Let’s build a network which can withstand a nuclear war!
1970s: Hm, that looks good, we’ll run it on TCP/IPv4.
1980s: Nice, how about letting everyone join?
1990s: Hey, you can make money out of this!
2000s: Oh, you can lose it, too.
2010s: Alright, let’s just plug absolutely everything into it.
2020s: Meh, my lightswitch is now connected to my lamp via China.
Please reply to the list;
please *don't* CC me.
Thanks sedwards.
Dialplan
exten => _7X.,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _7X.,n,Set(CALLERID(num)=+971xxxx2700)
exten => _7X.,n,Dial(PJSIP/${EXTEN:1}@connect,${CAMPDTO},To)
exten => _7X.,n,Hangup()
Getting This Error. And Speaking Your Number Is Incorrect.
Executing [043032000@default:1] AGI(“PJSIP/700-00000095”, “agi://127.0.0.1:4577/call_log”) in new stack
– <PJSIP/700-00000095>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
– Executing [043032000@default:2] Set(“PJSIP/700-00000095”, “CALLERID(num)=+971xxxx2700”) in new stack
– Executing [043032000@default:3] Dial(“PJSIP/700-00000095”, “PJSIP/043032000@connect,To”) in new stack
– Called PJSIP/043032000@connect
> 0x7fef34015000 – Strict RTP learning after remote address set to: 10.238.66.226:58306
– PJSIP/connect-00000096 is making progress passing it to PJSIP/700-00000095
> 0x7fef3401e580 – Strict RTP learning after remote address set to: 10.141.6.1:56022
> 0x7fef34015000 – Strict RTP switching to RTP target address 10.238.66.226:58306 as source
== Manager ‘sendcron’ logged off from 127.0.0.1
> 0x7fef3401e580 – Strict RTP switching to RTP target address 10.141.6.1:56022 as source
== Manager ‘updatecron’ logged off from 127.0.0.1
== Manager ‘updatecron’ logged on from 127.0.0.1
== Manager ‘updatecron’ logged off from 127.0.0.1
== Manager ‘updatecron’ logged on from 127.0.0.1
> 0x7fef34015000 – Strict RTP learning complete - Locking on source address 10.238.66.226:58306
> 0x7fef3401e580 – Strict RTP learning complete - Locking on source address 10.141.6.1:56022
== Manager ‘updatecron’ logged off from 127.0.0.1
== Manager ‘updatecron’ logged on from 127.0.0.1
== Spawn extension (default, 043032000, 3) exited non-zero on ‘PJSIP/700-00000095’
– Executing [h@default:1] AGI(“PJSIP/700-00000095”, “agi://127.0.0.1:4577/call_log–HVcauses–PRI-----NODEBUG-----127-----CANCEL---------------SIP 183 Session Progress)”) in new stack
– <PJSIP/700-00000095>AGI Script agi://127.0.0.1:4577/call_log–HVcauses–PRI-----NODEBUG-----127-----CANCEL---------------SIP 183 Session Progress) completed, returning 0
There is no error in that log. The caller hung up the call, during a call to 043032000 using a provider on endpoint connect.
Here is my Configuration and Endpoints.
[connect]
type=registration
transport=transport-udp
outbound_auth=connect
retry_interval=60
fatal_retry_interval=30
forbidden_retry_interval=30
max_retries=10000
expiration=3600
auth_rejection_permanent=no
line=yes
endpoint=connect
contact_user=+971xxxx2777
server_uri=sip:ims.etisalat.ae:5060
client_uri=sip:+971xxxx2777@ims.etisalat.ae:5060
outbound_proxy=sip:vims-siptrunk.etisalat.ae:5060
[connect]
type=auth
auth_type=userpass
password=xxxxxxxx
username=+971xxxx2777@ims.etisalat.ae
[connect]
type=aor
qualify_frequency=60
contact=sip:+971xxxx2777@ims.etisalat.ae:5060
outbound_proxy=sip:vims-siptrunk.etisalat.ae:5060
[connect]
type=identify
endpoint=connect
match=vims-siptrunk.etisalat.ae
[connect]
type=endpoint
transport=transport-udp
context=trunkinbound
disallow=all
allow=ulaw,alaw,gsm,g726,g722,h264,mpeg4
aors=connect
send_connected_line=false
rtp_keepalive=0
language=en
outbound_proxy=sip:vims-siptrunk.etisalat.ae:5060
outbound_auth=connect
from_domain=ims.etisalat.ae
contact_user=+971xxxx2777
user_eq_phone=no
t38_udptl=no
t38_udptl_ec=none
fax_detect=yes
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
send_rpid=no
send_pai=no
dtmf_mode=auto
force_rport=yes
rtp_symmetric=yes
I got the solution.
Thank you all of you to help me out.
The problem was I was using u-law which is European standard. I switch to a-law and Outgoing is working fine. (This can help others too).
I was using u-law which is European standard.
Just a little correction
u-law is used in the US and Japan (afaik)
a-law is used in Europe (and most other countries)
Have a nice day
Karsten
Le 11/04/2024 à 06:10, asterisknooob via Asterisk Community a écrit :
[asterisknooob] asterisknooob
https://community.asterisk.org/u/asterisknooob
April 11I got the solution.
Thank you all of you to help me out.
The problem was I was using u-law which is European standard. I switch
to a-law and Outgoing is working fine. (This can help others too).
This is not true: ulaw is North America & Japan, alaw is Europe
–
Daniel
Ops Yes Switch From U-law to A-law Works.
Thanks Daniel Yes May Be I Typed Opposite. Thanks For Correction.
Thank You All Of You.
And Big Thanks To David As Well.
@david551
God Bless You All.