SIP incoming calls not working

Asterisk Asterisk Support
1

[size=150]I have a SIP account & DID with my VoIP provider. The outgoing calls works fine, but incoming calls to the DID is not. When I call my DID from any external phones, I get my Telephone company saying “The number you are calling in not in service” recording.

9XXXXXX108373 is my DID number.[/size]

The Asterisk log shows:
<— Reliably Transmitting (NAT) to 94.77.210.150:5060 —>
[color=#FF4000]SIP/2.0 404 Not Found[/color]
Via: SIP/2.0/UDP 94.77.210.150:5060;branch=z9hG4bK365282-kmbdztn;cgp=terhal.go.com.sa;received=94.77.210.150;rport=5060
Via: SIP/2.0/UDP 94.77.211.66:5060;branch=z9hG4bK8a1b34e9b2fcfd08e114taN0
From: “0XXXX42334” tel:0XXXX42334;tag=ac1a2090-00007d2c000067cc
To: “+9XXXXXX108373” tel:+9XXXXXX108373;tag=as6fb50931
Call-ID: 00002bbd00005b00-0203-0049@172.26.32.144
CSeq: 31601 INVITE
Server: Asterisk Default
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0
<------------>
[color=#FF4000][Aug 1 14:57:37] NOTICE[4060] chan_sip.c: Call from ‘9XXXXXX108373’ to extension ‘s’ rejected because extension not found in context ‘GOterhalContext’.[/color]
[Aug 1 14:57:37] VERBOSE[4060] chan_sip.c: Scheduling destruction of SIP dialog ‘00002bbd00005b00-0203-0049@172.26.32.144’ in 6400 ms (Method: INVITE)
[Aug 1 14:57:37] VERBOSE[4060] chan_sip.c:
<— SIP read from UDP:94.77.210.150:5060 —>
ACK sip:s@188.53.78.210 SIP/2.0
P-CGP-Redirector: 9XXXXXX108373@terhal.go.com.sa
Via: SIP/2.0/UDP 94.77.210.150:5060;branch=z9hG4bK365282-kmbdztn;cgp=terhal.go.com.sa;rport
Max-Forwards: 63
From: “0XXXX42334” tel:0XXXX42334;tag=ac1a2090-00007d2c000067cc
To: “+9XXXXXX108373” tel:+9XXXXXX108373;tag=as6fb50931
Call-ID: 00002bbd00005b00-0203-0049@172.26.32.144
CSeq: 31601 ACK
Content-Length: 0

[size=150]I’m using Asterisk 1.6.2.24 installed on CentOS release 5.8 server.

I can only assume that Asterisk is could not locate context.

My Configuration is:[/size]

[color=#0000BF]sip.conf[/color]

[general]
.
.
register=>9XXXXXX108373:XXXXXX@terhal.go.com.sa

[GOterhal]
type=peer
host=terhal.go.com.sa
username=9XXXXXX108373
secret= XXXXXX
fromuser=9XXXXXX108373
fromdomain=terhal.go.com.sa
insecure=port,invite
canreinvite=no
disallow=all
allow=ulaw
allow=alaw
allow=g729
context=GOterhalContext

[color=#0040BF]extensions.conf[/color]
.
.
[GOterhalContext]
exten => 9XXXXXX108373,1,Dial(SIP/100,120,Tt)
exten => 9XXXXXX108373,n,Hangup()
exten => s,1,Dial(SIP/100,120,Tt)
exten => s,n,Hangup()

[color=#4080BF][size=150]Appreciate your help to have my VoIP/SIP incoming calls go through.[/size][/color] :smile:

2

Please do not shout!

Asterisk does not support “tel:” URLs.

Fortunately, it is treating them like SIP ones with an empty user, rather than rejecting them outright, so by actually defining the s extension, you could still handle them.

3

Thank you for your reply.

I am not shouting, I am just presenting my case clearly. :wink:

So how to handle it? Why I am unable to rout the incoming calls?

4

Ask your ITSP to use SIP URLs, instead, or look at the available functions, to see if there is one that gives your the raw URL, and parse it yourself.

This is not a normal problem so most ITSPs do or can provide SIP URLs.

It is also possible that currently supported versions of Asterisk do have some support for tel: URLs; yours is past end of life, even for security fixes.

Lots of large, bold, type doesn’t make reading easy so doesn’t make your case clear.

5

My debuging shows that the incoming calls can not find the context “GOterhalContext”.

Is that because of “tel:” URLs not supported?

6

Your debugging shows that you could not find extension “s” in that context. That is a bit surprising, as it does seem to be there. The “s” is the result of not understanding tel: URLs. I suppose they might be causing bogus generation of the not found in context message, but that is academic, as no bug report will be accepted against that version.

You are basically trying to do something that was never supported on that version on a version that won’t even be fixed if things that are supposed to be supported don’t work.

7

Ok, what version you recomend?

8

The latest 1.8 version if you want long term support (currently 1.8.15), or the latest 10 series version (10.8.0) if you want the most features, but are prepared for support to end soon.

You will need to look at the change logs to see if tel: support has been added. Obviously it is more likely to be in 10.x than 1.8.x. If it not listed, it will be a new feature so will not go in until at least the 11 series.

9

Unfortunately, I wont be able to upgrate to asteisk greater that 1.6 because I am using SANGOMA USBFXO devices that only suppoert asterisk 1.6.

Any other workaround.

You mentioned something about looking for available functions to see if there is one that gives your the raw URL, and parse it yourself.

Can you please elaborate more?

10

It would need to find you “s” extension for that.

Your best option is to get your service provider to provide SIP URLs.

11

Actually, asking the provider is the most difficult part, they do not understand what I am talking about.

How can I parse for s extention if it does not reach to the “GOterhalContext” context?

I deleted the whole context and still giving same message which means somehow it cannot find that context.

12

Try with:

[GOterhalContext] exten => s,1, yourstuffhere .....and here

13

If he is reporting his configuration correctly, he already has an extension s defined, but Asterisk appears to be denying that. Given the age of the system and the relative obscurity of the issue, I have no interest in trawling the source code to work out exactly what is wrong.

If the ITSP is unable to support Asterisk, they are either an incompetent ITSP or the OP is trying to abuse a service that is intended strictly for single user SIP phones, not for PABXes. The market for connecting Asterisk to ITSPs is so large that any ITSP who offers a service to connect to PABXes and is not familiar with Asterisk, should not be in the market.

I would argue that any ITSP who does not understand the difference between TEL: and SIP: also ought not to be in the market.

14

Gentlemen, many thanks, I will look for another provider. :frowning: