Need help in configuring dialplan for connecting three asterisk servers

I have three asterisk servers configured on below three servers,

Server1 - with PRI line
Server2 - with Internet connection
Server3 - cloud system

My use case is,
People will call on the PRI line (Server1) should be forwarded to Server2(with internet connection) and then this same call should be forwarded to Server3(Cloude system) so that customer calling on PRI line can talk to agent logged in on cloud system.

I need help in writing Dialplan to achieve this, please help me to do so.

Thanks in advance.

This forum is not for free design services. What we can do is help you understand what you are doing wrong, but, for that, you need to show us what you have tried and how it has failed.

Server 1: context of pri has dialplan that routes all call to server two. This is very similar to outgoing calls in the most common configuration.

Server 2: the same except that it is the context associated with the server 1 and the equivalent of the ITSP is server 3.

Server 3: normal incoming public network call configuration, with server 2 taking the role of ITSP.

Preferably use static addresses rather than registration, and consider authenticating both ways.

HI,

Thanks for reply.

What happening here is, call is received at the destination 1001 on server 3 but after i pick up the call it gets disconnected, but on the phone from which i dialed PRI number call gets answered and runs for exact 1 min.

what i have done so far is as below,

On server1(172.16.15.151),

I am making call on PRI number 0XX XXX88021 which in turn through dialplan calls the the sip trunk registered with server2(172.16.14.104).

[0XXXXX88021]
type = peer
username = 0XXXXX88021
secret = 0XXXXX88021
fromuser = 0XXXXX88021
host = 172.16.14.104
fromdomain = 172.16.14.104
nat = force_rport,comedia
disallow = all
;allow= g729
allow = ulaw,alaw
callerID=
insecure = very
context = default
directmedia = yes
port = 5060

On server2(172.16.14.104)

I have created peer with same username just to enter the dialplan,

[0XXXXX88021]
type = peer
username=0XXXXX88021
secret=0XXXXX88021
type=friend
host=dynamic
context=webinbound

Dialplan to call the trunk registered with server3

[webinbound]
exten => _X.,1,Dial(SIP/XXX88021,30,t)
same => n,Hangup()

Here trunk is created with the cloud server,

[XXX88021]
type = peer
username = XXX88021
secret = XXX88021
fromuser = XXX88021
host = (some_public_IP)
fromdomain = (some_public_IP)
nat = force_rport,comedia
disallow = all
allow= g729
allow = ulaw
callerID=
insecure = very
context = from-pstn
directmedia = yes
port = 5060

On Server3 (public IP cloud server)

Peer is created to execute the dialplan,

[68388021]
type=endpoint
transport=transport-udp-main
context=default
disallow=all
allow=ulaw,alaw
aors=68388021
auth=68388021

[68388021]
type=auth
auth_type=userpass
username=68388021
password=68388021

[68388021]
type=aor
max_contacts=5

Agent registered on sipml5 demo web application to receive call,

[3000]
type=aor
max_contacts=1
remove_existing=yes

[3000]
type=auth
auth_type=userpass
username=3000
password=web@123

[3000]
type=endpoint
aors=3000
auth=3000
dtls_auto_generate_cert=yes
webrtc=yes
context=inbound
disallow=all
allow=ulaw,alaw

Dialplan on server3 to call agent is,

[default]
exten => _XX.,1,Answer()
exten => _XX.,n,Dial(PJSIP/3000,60,T)
exten => _XX.,n,Hangup()

As you have NAT workaround options, but no NAT address options, please explain the routing configuration in use and, in particular, NAT boundaries, and mutual visibility of the network addresses.

As you control both ends of the links, there is no good reason to use insecure=very (which is a deprecated parameter). For the insecure=invite part, provide authentication in both directions, instead, and please explain why you need the insecure=port part. However note that these are reducing security, rather than actually causing a failure for the intended calls.

Is media working during the call?

Which entity is initiating the call clear. Please provide the SIP protocol traces involving that entity, and, if Asterisk, the logs, with sufficient verbosity to indicate the reason for clearing the call.

Hi,

What exact info you need please elaborate, i didn’t got your question…

If you are asking about external address for server2, there is no direct IP address assigned to it. Server2 is using the firewall public IP’s to communicate with outside world and firewall has 2 IP’s for load balancing.

Understood i will remove this parameter insecure=very

No, media is not working.

Server1 console output,

newserver-desktop*CLI> core set verbose 50
Console verbose was 15 and is now 50.
== Using SIP RTP CoS mark 5
> 0x7f72a801f590 – Strict RTP learning after remote address set to: 10.50.144.33:20446
– Executing [XXX88000@tata:1] Goto(“SIP/GATEWAY-00000112”, “s,1”) in new stack
– Goto (tata,s,1)
– Executing [s@tata:1] NoOp(“SIP/GATEWAY-00000112”, “”) in new stack
– Executing [s@tata:2] Set(“SIP/GATEWAY-00000112”, "pseudodid=“388021"sip:388021@10.50.144.33”) in new stack
– Executing [s@tata:3] Set(“SIP/GATEWAY-00000112”, “pseudodid=“388021”<sip:388021”) in new stack
– Executing [s@tata:4] Set(“SIP/GATEWAY-00000112”, “pseudodid=388021”) in new stack
– Executing [s@tata:5] Goto(“SIP/GATEWAY-00000112”, “tatadids,388021,1”) in new stack
– Goto (tatadids,388021,1)
– Executing [388021@tatadids:1] Dial(“SIP/GATEWAY-00000112”, “SIP/02268388021,30,r”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/0XXXXX88021
> 0x7f7280019ac0 – Strict RTP learning after remote address set to: 172.16.14.104:15824
– SIP/0XXXXX88021-00000113 answered SIP/GATEWAY-00000112
– Channel SIP/02268388021-00000113 joined ‘simple_bridge’ basic-bridge <7b4668d5-7e20-4e83-8893-0446b5dddca2>
– Channel SIP/GATEWAY-00000112 joined ‘simple_bridge’ basic-bridge <7b4668d5-7e20-4e83-8893-0446b5dddca2>
> 0x7f72a801f590 – Strict RTP switching to RTP target address 10.50.144.33:20446 as source
[Jun 29 21:04:57] WARNING[4954][C-00000086]: chan_iax2.c:1241 jb_warning_output: Resyncing the jb. last_delay 0, this delay -528828034, threshold 1000, new offset 528828034
– – G.729 PLC
> 0x7f72a801f590 – Strict RTP learning complete - Locking on source address 10.50.144.33:20446
– Channel SIP/0XXXXX88021-00000113 left ‘simple_bridge’ basic-bridge <7b4668d5-7e20-4e83-8893-0446b5dddca2>
– Channel SIP/GATEWAY-00000112 left ‘simple_bridge’ basic-bridge <7b4668d5-7e20-4e83-8893-0446b5dddca2>
== Spawn extension (tatadids, 388021, 1) exited non-zero on ‘SIP/GATEWAY-00000112’

Server2 console output,

cingulariti4*CLI> core set verbose 50
Console verbose was 15 and is now 50.
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
> 0x7f68ac05f640 – Strict RTP learning after remote address set to: 172.16.15.151:16596
– Executing [02268388021@webinbound:1] Dial(“SIP/0XXXXX88021-000002f8”, “SIP/68388021,30,t”) in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Called SIP/XXX88021
> 0x7f68380243a0 – Strict RTP learning after remote address set to: 15.206.18.152:12998
– SIP/XXX88021-000002f9 answered SIP/0XXXXX88021-000002f8
– Channel SIP/XXX88021-000002f9 joined ‘simple_bridge’ basic-bridge <7234fc21-b5e3-4767-8f5b-a9b1894aca2c>
– Channel SIP/0XXXXX88021-000002f8 joined ‘simple_bridge’ basic-bridge <7234fc21-b5e3-4767-8f5b-a9b1894aca2c>
> 0x7f68ac05f640 – Strict RTP switching to RTP target address 172.16.15.151:16596 as source
> 0x7f68ac05f640 – Strict RTP learning complete - Locking on source address 172.16.15.151:16596
[Jun 29 14:49:30] NOTICE[22159]: chan_sip.c:29865 check_rtp_timeout: Disconnecting call ‘SIP/XXX88021-000002f9’ for lack of RTP activity in 61 seconds
– Channel SIP/XXX88021-000002f9 left ‘simple_bridge’ basic-bridge <7234fc21-b5e3-4767-8f5b-a9b1894aca2c>
– Channel SIP/0XXXXX88021-000002f8 left ‘simple_bridge’ basic-bridge <7234fc21-b5e3-4767-8f5b-a9b1894aca2c>
== Spawn extension (webinbound, 0XXXXX88021, 1) exited non-zero on ‘SIP/0XXXXX88021-000002f8’

Server3 console output,

preprod-frontend*CLI> core set verbose 50
Console verbose was 15 and is now 50.
== Setting global variable ‘SIPDOMAIN’ to ‘some_public_ip’
– Executing [68388021@default:1] Answer(“PJSIP/XXX88021-00003e5a”, “”) in new stack
> 0x7f45b80212c0 – Strict RTP learning after remote address set to: 0.0.0.0:13210
> 0x7f45b80212c0 – Strict RTP qualifying stream type: audio
> 0x7f45b80212c0 – Strict RTP switching source address to 103.142.198.210:13210
– Executing [68388021@default:2] Dial(“PJSIP/XXX88021-00003e5a”, “PJSIP/3000,60,T”) in new stack
– Called PJSIP/3000
– Call on PJSIP/3000-00003e5b placed on hold
– Started music on hold, class ‘default’, on channel ‘PJSIP/3000-00003e5b’
– PJSIP/XXX88021-00003e5a requested media update control 26, passing it to PJSIP/3000-00003e5b
– PJSIP/3000-00003e5b is ringing
– PJSIP/3000-00003e5b is ringing
> 0x7f45b80212c0 – Strict RTP learning complete - Locking on source address 103.142.198.210:13210
– PJSIP/3000-00003e5b answered PJSIP/XXX88021-00003e5a
> 0x7f45b80296e0 – Strict RTP learning after remote address set to: 171.50.224.102:52749
– Channel PJSIP/3000-00003e5b joined ‘simple_bridge’ basic-bridge <0bb05dfa-5e2b-4326-ac85-d1ab713e2a5e>
– Channel PJSIP/68388021-00003e5a joined ‘simple_bridge’ basic-bridge <0bb05dfa-5e2b-4326-ac85-d1ab713e2a5e>
– Channel PJSIP/XXX88021-00003e5a left ‘simple_bridge’ basic-bridge <0bb05dfa-5e2b-4326-ac85-d1ab713e2a5e>
– Channel PJSIP/3000-00003e5b left ‘simple_bridge’ basic-bridge <0bb05dfa-5e2b-4326-ac85-d1ab713e2a5e>
== Spawn extension (default, XXX88021, 2) exited non-zero on ‘PJSIP/XXX88021-00003e5a’
– Stopped music on hold on PJSIP/3000-00003e5b

I get the feeling that we are getting important details in dribs and drabs. In particular the load sharing begs further questions.

It looks likeXXX88021 is initiating the clearing of the call.

The lack of media is probably due to having directmedia=yes in a NAT environment.

Server two, at least needs to have configuration to allow it to discover its public address.

It looks to me as though you have used cut and paste coding in a context that is sufficiently complex that the configuration needs to be done from first principles.

On server2 i figured out externhost was wrongly configured in sip general section

externhost=0.0.0.0

due to this server2 public ip address was not discovered on server 3

After this working scenario has changed,

Now call is getting connected and one way audio is also working for around 35 to 45 sec and call is getting disconnected after that i.e. audio is available from mobile to agent but agent to mobile audio is not available.

after this call on mobile continue to be connected for upto 1min and then it gets disconnected.

what could be the scenario in this case and how should i start troubleshooting in this?

Hi,

Can i get any answer for above situation

Can you provide the logging requested.

Do you need logging of all three servers?
What all logging to be enabled and what level?

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