Dialplan is not working properly

Asterisk Asterisk Dialplan
1

I created a dialplan to connect 2 asterisk servers one the main server using PJSIP 13 and another the client using the SIP 13 version too.

When I tried to receive a call in the main server for the extension 19009001 the client server didn’t pass the call to extension as the error bellow. I made many tests and only worked when I changed my dialplan to use “s”, but when I made it the ringing sound was with noises and in the log shows it:

ERROR test using “s” with noises:

2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]
  == Using SIP RTP CoS mark 5
    -- Executing [s@incoming:1] Answer("SIP/19009002-00000004", "") in new stack
    -- Executing [s@incoming:2] Dial("SIP/19009002-00000004", "SIP/19009001,60,tT") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/19009001
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009001-00000005 is ringing
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 26, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005
    -- SIP/19009002-00000004 requested media update control 20, passing it to SIP/19009001-00000005

ERROR when dialplan signal the endpoint 19009001

== Using SIP RTP CoS mark 5
> 0x7f1ab442a9a0 – Strict RTP learning after remote address set to: xx.233.162.33:11824
[Jan 25 18:01:00] NOTICE[16850][C-00000003]: chan_sip.c:26468 handle_request_invite: Call from ‘19009002’ (xx.233.162.33:5060) to extension ‘s’ rejected because extension not found in context ‘incoming’.

Dialplan desired and doesn’t work to receive call:

[incoming]
exten => 19009002,1,Answer()
  same => n,Dial(SIP/19009001,60,tT)
  same => n,Hangup()

Dialplan with “s” receiving calls and registering the flood of logs and noises:

[incoming]
exten => s,1,Answer()
  same => n,Dial(SIP/19009001,60,tT)
  same => n,Hangup()
2

May you please post the INVITE request because the “s” extension is used when there is no known called number in the context used.

3

This is the invite:

== Using SIP RTP CoS mark 5
> 0x7f1ab442a9a0 – Strict RTP learning after remote address set to: xx.233.162.33:11824
[Jan 25 18:01:00] NOTICE[16850][C-00000003]: chan_sip.c:26468 handle_request_invite: Call from ‘19009002’ (xx.233.162.33:5060) to extension ‘s’ rejected because extension not found in context ‘incoming’.
4

Oh no it isn’t.

You need to use sip set debug on to see it.

5 

<------------>
[Jan 26 23:28:40] NOTICE[16850][C-0004ebfe]: chan_sip.c:26468 handle_request_invite: Call from '19009002' (54.233.162.33:5060) to extension 's' rejected because extension not found in context 'incoming'.
Scheduling destruction of SIP dialog 'e74bf72e-17f7-4ba3-b8e0-84c04f273b73' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:54.233.162.33:5060 --->
ACK sip:s@52.67.101.31:5060 SIP/2.0
Via: SIP/2.0/UDP 54.233.162.33:5060;rport;branch=z9hG4bKPj1793efc5-d6ec-4984-acb8-4cf036ddf880
From: "5519999901569" <sip:5519999901569@172.31.3.118>;tag=77a661e3-cbad-49f8-bcf1-e6d3d9f3e967
To: <sip:s@52.67.101.31>;tag=as3e5ecb59
Call-ID: e74bf72e-17f7-4ba3-b8e0-84c04f273b73
CSeq: 19290 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 13.21.1
Content-Length: 0
6

That is not the INVITE request, even though the request URI is probably, although not necessarily, the same.

If it is the same, then the bit in the diagnostic about “s” is correct, so that is why your original dialplan doesn’t work.

The flood of noises suggests that something is mis-describing the codecs in uses. That isn’t a normal sort of problem.

On the other hand, control 20 is source of media has changed, and control 26 is the same but also requiring a new SSRC, which suggests something very wrong in the RTP being received from one side.

7

This is my SIP settings from the Asterisk client workin with version 13.21.1 and SIP:


[general]
context=basico
port=5060
bindport=5060
bindaddr=0.0.0.0
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
transport=udp
srvlookup=yes
maxexpirey=360
defaultexpirey=120
allow=all
externaddr=xx.67.101.31
media_address=xx.67.101.31
localnet=192.168.0.0/255.255.0.0
nat=force_rport,comedia
qualify=yes
directmedia=no

register => 19009002:***@**.233.162.33:5060

[19009002]
context=incoming
defaultuser=19009002
secret=*****
type=peer
host=**.233.162.33
port=5060
dtmfmode=rfc2833
qualify=yes
disallow=all
allow=alaw,ulaw
nat=force_rport,comedia
insecure=invite,port
directmedia=no

[19009001]
context=outbound
defaultuser=19009001
secret=*****
type=friend
host=dynamic
8

The reason you are getting s is that you haven’t specified an alternative contact address on the registers (and the ITSP is honouring the contact address.

Whilst noting that you haven’t constrained the codecs for 19009001, I don’t think that is relevant.

I think you are going to need to do some quite detailed logging to work out what your peers are doing wrong that is causing multiple source changes. I’d suggest using tcpdump an then wireshark (and try listening to the audio with wireshark).

9

well, how can I specify an alternative contact then?

10

I will do that, but the problem is not in the communication… the problem happens during the ring time. The noised is heard behind the ring sound, but when the call is attended it’s normal, without noises.

11

https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample from line 777. This files should have been supplied with your Asterisk.

12

Thank you very much.

I changed the registration as this document and worked the dialplan with 19009002 now:

I just add the extension in the end line registration as /19009002

Now only the problem with the noised during the ring time, I will make the tcpdump

13

Just dont know why to use register string if you have static IP on both servers

14

This is the tcpdump opened in wireshark:

image
image1734×1040 84 KB

15

The problem appears to be in the RTP handling, and my guess is that you will need to do a lot of the analysis work yourself as this going to involve too many interactions and too much time to be done, effectively, by the forum.

16

ok thank you, I will try to do that.