Can't make incoming calls

I have two extensions.
I have tested the extensions by registering two softphones and having them dial each other and that works fine.

I’m writing a library that implements SIP.
I’m using gstreamer to handle RTP.
So in other words, I am sending raw sip directly to freepbx.

SNIP [CANT POST LINKS AS A NEW USER]

Notice on line 54, freepbx sent a CANCEL request right after the softphone responded with a TRYING after freepbx routed the INVITE. I don’t know why freepbx is canceling?

Anyway, the call doesn’t go through. In other words, it doesn’t cause the softphone I am calling to ring. Eventually, the gstreamer rtp stream gets audio saying “the person at that extension 2001 is unavailable please leave your message…”.

I’ve got links to images of my freepbx settings and the logfiles. But can’t post links on this forum. May I post links?

This sounds like this relates to the Asterisk part of FreePBX, rather than the FreePBX part, so is likely to be much easier to debug if you construct a minimal Asterisk configuration, and use the Asterisk peer support forum https://community.asterisk.org/

However, to continue here, you should either use pastebin.freepbx.org, and post the final part of the URL here, or you take just the “psjsip set logger on” output, and paste it inline, marking it as preformatted text (which will stop it being misinterpreted as containing URLs, as well as preventing it being garbled).

Generally Asterisk will only cancel, if the incoming side hangs up (or cancels) or the outgoing call or the whole call is times out.

PS I’ve only given the pjsip command, as you should not be using deprecated channel drivers for this sort of exercise.

I was already going by the asterisk docs and tutorials to setup a minimum environment. But I used your link to paste the logs.

This is the asterisk log containing only the sip messages
https://pastebin.freepbx.org/view/246be9ed

This is the asterisk log containing only the asterisk debug info
https://pastebin.freepbx.org/view/e0723bde

More interestingly, this is the log from the softphone I was trying to call. Notice the CANCEL request from asterisk.
https://pastebin.freepbx.org/view/0f6985ae

10.0.0.106 is my host ip where I am sending the sip messages from. It’s also where the softphone is at.
10.0.0.102 is where freepbx is located.
My host ip is whitelisted on the firewall. No problems with getting the sip messages to asterisk.

There is no evidence, other than the received user agent, that Asterisk sent the CANCEL. CANCEL would always be included in the logging.

The full log ends with an ongoing call and shows no evidence that Asterisk has recognized a failure, or terminated the call itself.
Blink has failed to send OK and transaction terminated, in response to the CANCEL.

Blink is being very slow in sending any substantive provisional response, although whilst some service providers would abort because of this, I don’t think Asterisk will and Asterisk has sent responses that will keep the provider happy.

Although your logs are clearly truncated, the CANCEL was correctly sent at the 15 second timeout that you specified in the DIal application call:

231 [2021-10-23 03:44:59] VERBOSE[26782][C-0000003b] pbx.c: Executing [[email protected]:56] Dial("PJSIP/anonymous-0000006c", "PJSIP/2001/sip:[email protected]:42955,15,HhTtrb(func-apply-sipheaders^s^1)") in new stack

Blink (which I know nothing about) responded to the incoming INVITE with 100 Trying but there was no further communication (until Asterisk timed out and Blink was sent a CANCEL). I assume that is because the request was malformed in a way it could not handle.

The original request from your app shows
From: "Alice" <sip:10.0.0.106>;tag=1928301774
with a null string where the caller ID would go; it should be e.g.
From: "Alice" <sip:[email protected]>;tag=1928301774
Asterisk passed the null caller ID to Blink, which may explain why it did not respond.

Another strange item is that the call from your app was treated as ‘external’; it was not recognized as coming from an extension or trunk. How should it be handled?

Finally, Asterisk offered many codecs to Blink. At least for testing, you may want to configure its extension for ulaw only, in case the others somehow confused Blink.

After fixing the above, if you still have trouble, please paste the complete Asterisk log for a failing call, with the pjsip logger messages interspersed with the Asterisk messages.

1 Like

That’s a perfectly valid SIP URI. No user name is needed if the whole device is being addressed.

Yes, I never said that any RFCs are being violated. A Softphone that I know nothing about is misbehaving (according to its own log). I mentioned various unusual items, one of which may have caused Blink to malfunction. I assume that the OP was not intending to send a null caller ID. Possibly he wanted ‘anonymous’, but that’s not the same as null.

So what’s the OP to do? One option is to push down and chase why Blink is failing to respond properly, but that could be a deep rabbit hole. Another is to replace Blink with e.g. Linphone in the hope that it will tolerate the null caller ID. But, assuming that he didn’t intend to send a null caller ID, IMO he should fix that then continue working from whatever results.

My understanding was that Blink is the OP’s homebrew SIP user agent, so not negotiable, but changeable.

Adding [email protected] to the From header worked! Okay so this wasn’t a freepbx issue, it was a user agent error.

As an aside, you mentioned I wasn’t originating the call from a trunk or an extension. That is true, it’s just my own sip lib I’m implementing in rust and hosted on the same network as asterisk and the blink softphone.

I’m still trying to understand how everything connects in voip, and implementation is part of the journey to get me to that understanding. But would I need a sip trunk to call in from my own UA? I thought it was only required to get your line connected from the public telephone services? My setup is that I have freepbx running in a vm, blink running on the same computer outside the vm and my sip lib running on the same computer outside the vm.

I didn’t want to register the implementation of a UA as an extension, because I wanted to test incoming calls from non registered UA as if from the outside. Though, I understand I would need a trunk if this has to traverse public telephony?

Again, thank you for looking into the sip messages with keen eyes and spotting the header discrepancy.

Trunk and extension are abstractions that FreePBX create, they are not SIP concepts, and not Asterisk concepts. If you want to use FreePBX, then you need to determine whether your UA is an extension or a trunk, in FreePBX terms, for any given scenario. To a significant extent they are abstractions that are trying to emulate concepts from legacy telephone systems (although this is actually true of how SIP is used in the real world, when exposed directly to end users (some proprietary VoIP systems, that you might have thought of as VoIP, as they come with names like Messenger, have used SIP under the hood, in ways that don’t make everything look like traditional phone numbers).

This extra layer of abstraction and the amount of under the hood complexity is why, for your unusual, requirement, you would be better off using bare Asterisk, where, for your purposes, a single “priority” dialplan is likely to adequate and far less confusing, than the 100 or so lines of dialplan code that FreePBX executes in order to create the abstraction on which its GUI operates.

I’d go as far as to suggest that if you want to play with low level SIP concepts, you should use a second instance of Asterisk as your custom user agent, and then progress to using SIPP, if you want to experiment with things that Asterisk cannot originate itself. SIPP is a tool for testing SIP implementations.

If you work with FreePBX you will either end up learning more about how it works than how VoIP in general works, or end up bypassing most of what it provides, but getting confused by the parts of it that you keep.

2 Likes

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