Incoming call issue with Asterisk

[Jose Soto]

Hi All,

 

I am hitting the wall with an incoming call issue I am having with the MP using Vitelity.net DIDs.

 

This is the situation:

I can make calls outbound via Vitelity.

I can make calls and receive calls from extensions on the mesh

BUT

I can not receive calls inbound from the Vitelity DID using the MP.

 

I have full functionality (inbound and out) with a softclient and via a Linksys PAP2 adapter.

 

I have attempted to use several numbers I have with Vitelity. All have this same outcome.

 

It looks like a configuration issue in Asterisk or somewhere on the MP.

 

Below is what I see in Asterisk diagnostics:

 

 　

MP-24*CLI> sip show registry

Host Username Refresh State Reg.Time

inbound2.vitelity.net:5060 myUserName 45 Registered Sun, 01 Jan 2012 09:13:40

In /var/log/messages, I see

[Jan 1 10:01:20] NOTICE[30322] cdr.c: CDR simple logging enabled.

[Jan 1 10:01:20] NOTICE[30322] loader.c: 54 modules will be loaded.

[Jan 1 10:01:20] WARNING[30322] loader.c: Error loading module 'app_cut.so': File not found

[Jan 1 10:01:20] WARNING[30322] res_smdi.c: No SMDI interfaces are available to listen on, not starting SDMI listener.

[Jan 1 10:01:21] NOTICE[30329] chan_sip.c: Peer 'vitel-outbound' is now Reachable. (58ms / 5000ms)

[Jan 1 10:01:21] WARNING[30322] loader.c: Error loading module 'app_cut.so': File not found

[Jan 1 10:01:21] WARNING[30322] loader.c: Module 'app_cut.so' could not be loaded.

[Jan 1 10:01:21] NOTICE[30329] chan_sip.c: Peer 'vitel-inbound' is now Reachable. (59ms / 5000ms)

[Jan 1 10:01:21] NOTICE[30329] chan_sip.c: Peer 'sipaccount' is now Reachable. (65ms / 2000ms)

　　

This is what I see when incoming calls (2):

Really destroying SIP dialog '487aff0a556bbf60...@64.2.142.27' Method: ACK

Really destroying SIP dialog '6733bd857d6ccdc0...@64.2.142.27' Method: ACK

　

What I see out successful outgoing call:

MP-24*CLI> sip show channels

Peer User/ANR Call ID Seq (Tx/Rx) Form Hold Last Message

64.2.142.27 3863371111 5c4e9eb0487 00103/00000 gsm No Tx: INVITE

64.2.142.27 myUserName 78facb5706f 00137/00000 unkn No

2 active SIP channels

-- event_digit_timer

-- extension exists, starting PBX #3863374557

-- Executing [#3863371111@default:1] Dial("MP/1", "SIP/3863371111@sipaccount|120|r") in new stack

-- Called 3863371111@sipaccount

-- Asked to indicate 'Remote end is ringing' condition on channel MP/1

-- SIP/sipaccount-00581618 is making progress passing it to MP/1

________________________________________

 I saw something strange while further debugging.

When Asterisk loads this is what I see:

  == Parsing '/etc/asterisk/asterisk.conf': Parsing /etc/asterisk/asterisk.conf
Found
  == Parsing '/etc/asterisk/extconfig.conf': Parsing /etc/asterisk/extconfig.conf
Found
Connected to Asterisk 1.4.11 currently running on MP-24 (pid = 1108)
Verbosity was 0 and is now 4
Core debug was 0 and is now 2
    -- Remote UNIX connection

This is what I see on incoming call attempt  (Caller connects then call drops)
    -- Executing [787336XXXX@inbound:1] Answer("SIP/myUsename-0056c1d0", "") in new stack
  == Auto fallthrough, channel 'SIP/myUsename-0056c1d0' status is 'UNKNOWN'

---------------------------------
Two questions:

1. This is what is in extconfig.conf Should this be BLANK ??

root@MP-24:/etc/asterisk# cat extconfig.conf
; Static and realtime external configuration

[settings]
root@MP-24:/etc/asterisk#

2. Incoming Caller connects then call drops. What is the Auto fallthrough and how to config?
Auto fallthrough, channel 'SIP/myUsername-0056c1d0' status is 'UNKNOWN'

Any clue what is triggering this issue?

I look to the group as the source of  wisdom for clarity on the issue.

Thanks,
Jose'

 

 

 

 

[Keith Williamson]

Hi Jose,

Did you setup dialplan entries in the default context (in potato.extensions.conf) that handles each incoming DID? 

Since I just have a single DID with my VSP, for testing I sometimes setup a dialplan entry for the DID number that autoanswers, provides a voice prompt to enter an MP extension number, waits for the user to enter the extension, then calls that extension. Sometimes I just set it up without an auto-attendant dialplan and instead just do a simpler dialplan entry that sends the incoming call to a specific MP extension. Either way, you have to create a dialplan entry for the DID (or each DID in your case) in potato.extensions.conf. 

Cheers,

Keith

Really destroying SIP dialog '487aff0a556bbf60341eb92b1a6286...@64.2.142.27' Method: ACK

Really destroying SIP dialog '6733bd857d6ccdc0350cefc359f4e6...@64.2.142.27' Method: ACK

ro...@MP-24:/etc/asterisk# cat extconfig.conf

; Static and realtime external configuration

[settings]
ro...@MP-24:/etc/asterisk#

[Wayne Abroue]

Hi Jose

You can do this with A2billing, just map the DID to a extension.
Any incoming DID can get rerouted directly to whatever extension you
select, OR as Keith says, setup a IVR to inquire extension number.
I prefer the direct method as DID's will be then be exclusively and
transparently used by a individual MP/softphone.
Internal calling then is also reachable via the dialed DID routed
internally. In effect giving a Node it's unique number to be used
externally and internally.

Wayne

>> '487aff0a556bbf60...@64.2.142.27' Method: ACK
>>
>> Really destroying SIP dialog
>> '6733bd857d6ccdc0...@64.2.142.27' Method: ACK

> --
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To post to this group, send email to village-...@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/village-telco-dev/-/7Wb1a0Y7k_oJ.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[T Gillett]

Hi All

just for info, I have tested a Vitelity account on an MP here and inbound calls work fine,

So it looks more like a networking issue rather than a firmware or configuration issue.

Regards
Terry

[Abdoulaye Siby]

Hello Jose

As a general rule of thumb that we have established for ourselves, you should avoid having provider specific information inside the Mesh Potato devices. This makes it so difficult to track how which MP has been configured. Imagine having 100s of MPs.

We believe that one should always have a switching platform (as suggested in the model used for the DILI village configuration by Steve Song) between the outside world and your MP devices. That is needed for both the more secured layout and the practicality.

For example, in your case, to have a working inbound route:

1. You can have an Asterisk server connected to both the outside world and your Mesh network (different networks for a good isolation). This does not need to be a very powerful server. It can even be an IP0X device. But feel free to use a real server sized according to your needs.
2. Make sure that the Asterisk server can be reached by dialing the DID numbers.
3. Do not register the MP devices with Asterisk. This is a private MP network. If the MP is not reachable, you will receive the appropriate message that can be handled easily in Asterisk. You will be amazed by the overhead of too many MPs registering with Asterisk and re-registering every 60 seconds (default with Asterisk). IP authentication is way better, and is more stable than registering. We have learned that the hard way during the years spent in the VoIP business.
   
4. Configure an extension for each DID number and bridge the incoming calls to the corresponding MP. Basically, you dialout to 40...@a.b.c.d where a.b.c.d is the IP of the MP that you want to associate with the give DID. This can be done either manually (keep things simple) or using something like freePBX depending on the capacity of the Asterisk Server. Remember, if the MP is turned of or not reachable, you will instantly receive the corresponding dial status as a result of trying to dial out to the MP. Make sure that your extension can handle that and either send to a voice mail or play an audio response back to the caller (congestion voice message, fast busy tone, ...).
   

Many people will theorize about using A2Billing for the job. Although is it well possible, I see it as being an overkill. First, it rules out the use of an IP0X, an other embedded devices. The reason is simple. You will need to install PHP and MySQL at the very least. This means using up a large part of the valuable flash memory ... not to mention the limited RAM available and the configuration puzzles and the learning curve if you have never used it.

And remember this ... for a programmer the only way to avoid bugs in a line of code is not to write any code at all.

Similarly, you should stick to the strict rule of using only components that are absolutely necessary in your MP based infrastructure.

Cheers

A. $iby

[T Gillett]

Hi Abdoulaye

Thanks for sharing your experiences. I am particularly interested in your comments around using low end devices to act as gateways and centralised the Asterisk management.

I have been thinking about using the TP Link WD842ND and WDR4300 devices as possibilities for this purpose. These have 32 and 128 Mb Ram respectively and cost $50 / 100 each. They have USB ports so flash memory is essentially unlimited.

From our work with the TP Link WR703N and other devices we now have a well developed process for setting them up with OpenWrt, Asterisk and Village Telco firmware.

I would be interested in your view as to whether these devices are likely to be suitable for use in the role you outlined.

If so I would like to work towards developing a standard firmware image for this purpose to make it easy for people to set up networks as you describe.

Regarding the MP SECN SIP / VoIP set up, the intention is to support a simple use case of an individually managed account used on a single device.

The set up requires only the entry of the SIP account credentials and Asterisk restart in order for the device to register and make incoming and outgoing calls. There is no requirement to modify any config files for this simple use case.

This simple set up al

--

You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/ay4gU2Rj7YUJ.

[T Gillett]

And the rest of the message...

This simple set up also allows the use of the
sip acct by attached softphones if required.

It is critical that the network config of the MP and the LAN is correct to allow the MP to access the sip host over the internet.
Basically the MP has to be in the correct LAN subnet with access to the gateway and DNS.

It will be interesting to see what the problem with Jose's set up turns out to be since the Vitelity accounts work fine on MPs in my test set up.

Regards
Terry

[Wayne Abroue]

> --

Hi Abdoulaye Et Al

I was also very interested in your take on using a *small* device as a
asterisk server/router. While I'm sure it is entirely possible, I'm
not so sure it can fulfill all scenario's.

I will definitely look into the IP auth to reduce overhead.

My biggest concern would be transcoding, as many providers require
i.e. G729, and for this no embedded unit will suffice, unless we
licence each MP.
Even a 2G/ 1G ram machine has trouble in this scenario.
The other concern is when multiple users are required, how would
billing pre/post then be handled?
Would the idea be to offload billing/php/mysql onto another separate machine?

Wayne