Dial in dialplan - dial out forward call

Asterisk Asterisk Support
1

Hi

Sorry for newbe question.

I need to create a dialplan for incoming calls, but users registred on asterisk can dial out with numer registred as trunk.

Dialplan for incoming calls from outside:

[from-sip-external] exten => s,1,Playback(ST_witamy_w_media) exten => s,n,GotoIfTime(8:00-18:00,Mon-Fri,*,*?lbl_from-sip-external_0) exten => s,n,Playback(ST_nie_pracujemy_w_godz) exten => s,n,Hangup()

sip_additional.conf

[quote][INSIDE_TRUNK]
host=host.for.sip
username=LOGIN
secret=PASSWORD
type=friend
insecure=port,invite
allow=all
context=from-sip-external
nat=yes
fromuser=EX_NUMBER
canredirect=yes
canreinvite=no
realm=HOST

[6660]
deny=0.0.0.0/0.0.0.0
secret=PASSWD
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
nat=yes
port=5060
qualify=yes
qualifyfreq=60
transport=udp
encryption=no
callgroup=
pickupgroup=
dial=SIP/6660
mailbox=6660@device
permit=0.0.0.0/0.0.0.0
callerid=device <6660>
callcounter=yes
faxdetect=no

[SIP-TRUNK]
host=HOST
username=LOGIN
secret=PASSWD
type=user
insecure=port,invite
allow=all
context=from-sip-external
fromuser=NUMBER
qaulify=yes[/quote]

registred work fine.

The question is, if I use type=user for incoming calls and type=user for outcoming work greate and dialplan can communicate with me, but users need trunk (as I think) to call outside. If is use type=peer for outcoming and type=user for incoming call local users can call outside but dialplan for incoming call not working :frowning: can someone help me with this? how to fix this. I lost my hope.

2

This is answered as though you weren’t using a GUI and sip.additonal.conf was actually sip.conf.

qualify is spelled wrongly.

Normally you should use type = peer for all SIP device entries.

You are referencing contexts defined by the GUI. The contents of those contexts is critical to any question of selective routing. You should not assume people here know how your GUI works.

You need to provide CLI output, preferably at least verbosity 3, to show the symptoms of the failure.

3

[code]<------------>
– Executing [s@from-trunk:1] NoOp(“SIP/123965447-00000060”, “No DID or CID Match”) in new stack
– Executing [s@from-trunk:2] Answer(“SIP/123965447-00000060”, “”) in new stack
Audio is at 13458
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x100 (g729) to SDP
Adding codec 0x400 (ilbc) to SDP
Adding codec 0x800 (g726) to SDP
Adding codec 0x1000 (g722) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<— Reliably Transmitting (NAT) to 79.133.197.55:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 79.133.197.55;branch=z9hG4bK309c.49851b3.0;received=79.133.197.55;rport=5060
Via: SIP/2.0/UDP 79.133.197.56:5060;branch=z9hG4bK2a9819fd
Record-Route: sip:79.133.197.55;lr=on
From: “505619318” sip:505619318@79.133.197.56;tag=as4db51372
To: sip:123965447@79.133.197.55;tag=as777d98a2
Call-ID: 38658bd10b5055aa0fb3e6ef607899b2@79.133.197.56:5060
CSeq: 102 INVITE
Server: FPBX-2.10.0rc1(1.8.11)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:s@178.33.50.65:5060
Content-Type: application/sdp
Content-Length: 433

v=0
o=root 572512667 572512667 IN IP4 178.33.50.65
s=Asterisk PBX 1.8.11-cert8
c=IN IP4 178.33.50.65
t=0 0
m=audio 13458 RTP/AVP 0 8 3 18 97 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>

<— SIP read from UDP:79.133.197.55:5060 —>
ACK sip:s@178.33.50.65:5060 SIP/2.0
Via: SIP/2.0/UDP 79.133.197.55;branch=z9hG4bK309c.49851b3.2
Via: SIP/2.0/UDP 79.133.197.56:5060;branch=z9hG4bK328f3170
Max-Forwards: 69
From: “505619318” sip:505619318@79.133.197.56;tag=as4db51372
To: sip:123965447@79.133.197.55;tag=as777d98a2
Contact: sip:505619318@79.133.197.56:5060
Call-ID: 38658bd10b5055aa0fb3e6ef607899b2@79.133.197.56:5060
CSeq: 102 ACK
User-Agent: easyCALL VoIP server
Content-Length: 0
P-hint: rr-enforced

<------------->
— (12 headers 0 lines) —
– Executing [s@from-trunk:3] Wait(“SIP/123965447-00000060”, “2”) in new stack
– Executing [s@from-trunk:4] Playback(“SIP/123965447-00000060”, “ss-noservice”) in new stack
– <SIP/123965447-00000060> Playing ‘ss-noservice.ulaw’ (language ‘en’)
– Executing [s@from-trunk:5] SayAlpha(“SIP/123965447-00000060”, “”) in new stack
– Executing [s@from-trunk:6] Hangup(“SIP/123965447-00000060”, “”) in new stack
== Spawn extension (from-trunk, s, 6) exited non-zero on ‘SIP/123965447-00000060’
– Executing [h@from-trunk:1] Macro(“SIP/123965447-00000060”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“SIP/123965447-00000060”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] Hangup(“SIP/123965447-00000060”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 3) exited non-zero on ‘SIP/123965447-00000060’ in macro ‘hangupcall’
== Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/123965447-00000060’
Scheduling destruction of SIP dialog ‘38658bd10b5055aa0fb3e6ef607899b2@79.133.197.56:5060’ in 6400 ms (Method: ACK)
set_destination: Parsing sip:79.133.197.55;lr=on for address/port to send to
set_destination: set destination to 79.133.197.55:5060
Reliably Transmitting (NAT) to 79.133.197.55:5060:
BYE sip:505619318@79.133.197.56:5060 SIP/2.0
Via: SIP/2.0/UDP 178.33.50.65:5060;branch=z9hG4bK063b536e;rport
Route: sip:79.133.197.55;lr=on
Max-Forwards: 70
From: sip:123965447@79.133.197.55;tag=as777d98a2
To: “505619318” sip:505619318@79.133.197.56;tag=as4db51372
Call-ID: 38658bd10b5055aa0fb3e6ef607899b2@79.133.197.56:5060
CSeq: 102 BYE
User-Agent: FPBX-2.10.0rc1(1.8.11)
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0[/code]

I have put context back to default. In this dialplan should be hired “ss-noservice.ulaw” but there is no sound just silent and hangup

4

I would say you had a firewall or router problem, for the RTP packets, not an Asterisk one.