Vega - Blocked CallerID Received as Anonymous Inbound SIP Call

rymes · January 22, 2020, 5:29pm

We have a T1 PRI connected to our FreePBX system via a Sangoma Vega 100G and we found that callers with blocked CallerID were unable to get through, receiving an error recording that the line was disconnected. A little time in the FreePBX logs showed that the PBX was receiving the call as an anonymous SIP connection, while the calls without blocked CallerID came in as a normal authenticated call over a trunk. We enabled the setting to “Allow Anonymous Inbound SIP Calls” and this resolved our issue, but that seems like we’re treating the symptom, and not the cause, so I’m hoping someone can point me in the right direction to fix this.

A call with blocked CallerID comes in to the “from-sip-external” context, along with the note “Received incoming SIP connection from unknown peer to…”

[2020-01-22 12:02:06] VERBOSE[31414][C-0000279e] pbx.c: Executing [2071234567@from-sip-external:1] NoOp("PJSIP/anonymous-00010b2c", "Received incoming SIP connection from unknown peer to 2071234567") in new stack

A call with normal CallerID comes into the “from-pstn” context with no warnings:

[2020-01-22 12:03:48] VERBOSE[31644][C-000027a1] pbx.c: Executing [2071234567@from-pstn:1] Set("PJSIP/VegaPJSIP-00010b40", "__DIRECTION=INBOUND") in new stack

I also SSHed into the Vega and enabled “log display on” and got the following details:

Blocked CallerID:

LOG: 01/22/2020 17:01:44.600 TELNET   (C)R01C00 (user:admin)log display on
LOG: 01/22/2020 17:02:05.510 ISDN     (I)R01C17 incoming
   call ref=[f17505a5]                          srce= [0]
LOG: 01/22/2020 17:02:05.510 ROUTER   (I)R0bC00 FINDROUTE profile:20(To_SIP) plan:1
   call ref=[f17505a5]                            <-- ISDN    [1,1] dest=TEL:2071234567
                                                  --> SIP     [2,1] dest=TEL:2071234567
LOG: 01/22/2020 17:02:05.510 ROUTER   (I)R0bC00 call proceeding
   call ref=[f17505a5]
LOG: 01/22/2020 17:02:05.640 SIP      (I)R03C0b connect g711Ulaw64k (Profile 1 - Voice)
   call ref=[f17505a5]
LOG: 01/22/2020 17:02:11.660 ISDN     (I)R04C17 disconnect 16
   call ref=[f17505a5]
LOG: 01/22/2020 17:02:11.660 ISDN     (I)R04C17 send release 16
   call ref=[f17505a5]
LOG: 01/22/2020 17:02:11.660 SIP      (I)R04C10 disconnect(disc req) 16
   call ref=[f17505a5]

Regular CallerID:

LOG: 01/22/2020 17:03:39.065 TELNET   (C)R01C00 (user:admin)log display on
LOG: 01/22/2020 17:03:47.590 ISDN     (I)R01C15 incoming
   call ref=[f17505a3]                          srce=TEL:2077654321 [0]
LOG: 01/22/2020 17:03:47.590 ROUTER   (I)R0bC00 FINDROUTE profile:20(To_SIP) plan:1
   call ref=[f17505a3]                            <-- ISDN    [1,1] dest=TEL:2071234567
                                                  --> SIP     [2,1] dest=TEL:2071234567
LOG: 01/22/2020 17:03:47.590 ROUTER   (I)R0bC00 call proceeding
   call ref=[f17505a3]
LOG: 01/22/2020 17:03:47.695 SIP      (I)R03C0e connect g711Ulaw64k (Profile 1 - Voice)
   call ref=[f17505a3]
LOG: 01/22/2020 17:03:52.865 ISDN     (I)R04C15 disconnect 16
   call ref=[f17505a3]
LOG: 01/22/2020 17:03:52.865 ISDN     (I)R04C15 send release 16
   call ref=[f17505a3]
LOG: 01/22/2020 17:03:52.865 SIP      (I)R04C10 disconnect(disc req) 16
   call ref=[f17505a3]

The only real difference I can see is between “srce=TEL:2077654321 [0]” and “srce= [0]” on the third line. Otherwise it seems to connect just fine and selects the same profile in the dialplan, etc.

Can anyone shed some light on this? Why is FreePBX receiving some calls as anonymous SIP connections, while others come in on a configured trunk?

Tom

sorvani · January 22, 2020, 9:49pm

I think the better question is why the Vega is sending it that way?

Get debug of the pjsip or sip traffic to prove what is coming in.

rymes · January 23, 2020, 8:26pm

OK, I got some debug information, and this is what I found. The Vega is clearly sending the “Restricted” call as an anonymous inbound SIP call, while the non-restricted call is sent as coming from the Vega itself:

<--- Received SIP request (1073 bytes) from UDP:192.168.123.108:5060 --->
INVITE sip:[email protected]:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.123.108:5060;rport;branch=z9hG4bK-vega1-D71426D674DA-000A-0001-CC89-0F3C4403
From: "Anonymous" <sip:[email protected]>;tag=00F5-6A5C-67409499
To: <sip:[email protected]>
Max-Forwards: 70
Call-ID: 00F0-A79F-E2AF8AA2-00000063@8FAC424A9B3B07A9F
CSeq: 1400407880 INVITE
Contact: <sip:[email protected]:5060>
Supported: replaces, privacy, norefersub, pw-info-package
Allow: INVITE,ACK,BYE,CANCEL,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE,UPDATE
Accept-Language: en
Content-Type: application/sdp
Privacy: id
P-Preferred-Identity: "Anonymous" <sip:[email protected]>
User-Agent: VEGA/15.02.12.0xS010
Content-Length: 357

v=0
o=Vega 1386989 1386989 IN IP4 192.168.123.108
s=Sip Call
c=IN IP4 192.168.123.108
t=0 0
m=audio 11274 RTP/AVP 18 0 8 4 13 98 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:13 CN/8000
a=rtpmap:98 CLEARMODE/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,16
a=fmtp:18 annexb=no
a=sendrecv

When the call is from a number that does not have restricted CallerID, the call is sent as [email protected], as you would expect:

<--- Received SIP request (1074 bytes) from UDP:192.168.123.108:5060 --->
INVITE sip:[email protected]:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.123.108:5060;rport;branch=z9hG4bK-vega1-D71426D674DA-000A-0001-A882-CF56972A
From: "6035551212" <sip:[email protected]>;tag=00F8-369A-B9983565
To: <sip:[email protected]>
Max-Forwards: 70
Call-ID: 00F2-C420-AF8FB2D0-00000063@8FAC424A9B3B07A9F
CSeq: 1400544080 INVITE
Contact: <sip:[email protected]:5060>
Supported: replaces, privacy, norefersub, pw-info-package
Allow: INVITE,ACK,BYE,CANCEL,INFO,NOTIFY,OPTIONS,REFER,SUBSCRIBE,UPDATE
Accept-Language: en
Content-Type: application/sdp
Privacy: none
P-Preferred-Identity: "6035551212" <sip:[email protected]>
User-Agent: VEGA/15.02.12.0xS010
Content-Length: 357

v=0
o=Vega 1387145 1387145 IN IP4 192.168.123.108
s=Sip Call
c=IN IP4 192.168.123.108
t=0 0
m=audio 11290 RTP/AVP 18 0 8 4 13 98 101
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:13 CN/8000
a=rtpmap:98 CLEARMODE/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,16
a=fmtp:18 annexb=no
a=sendrecv

rymes · January 23, 2020, 8:45pm

Looking through the Vega setup, I can control the user portion of “[email protected]” in the SIP Advanced settings for the Vega, but I do not see where the "anonymous.invalid can be modified.

rymes · January 25, 2020, 7:58pm

Any Vega gurus out there that can explain why calls with blocked CallerID are being sent to Asterisk as anonymous SIP calls, instead of calls from the Vega over the trunk? @sorvani ?

lgaetz · January 26, 2020, 4:49pm

Looks like you’re using a PJSIP trunk to the Vega. See Asterisk SIP Settings, PJSIP tab and check the Endpoint Identifier Order. Assuming your Vega has a fixed ip, you want IP to come before Anonymous.

rymes · January 26, 2020, 5:19pm

Thanks for the pointer, Lorne. Looks like we already have it set that way, though.

Could this be related to the “Local Domain” Setting on the Vega in the SIP profile? I have noticed that it is set to the IP of the PBX, and not the IP of the Vega, and that just seems wrong to me. You can see that the “P-Preferred-Identity” and ther “From:” in the normal call both use the x.x.x.107 (PBX) IP address, not the x.x.x.108 (Vega) IP address.

lgaetz · January 26, 2020, 5:36pm

Try reversing the positions of IP and Username. Settings, Asterisk SIP Settings, PJSIP Tab

rymes · January 26, 2020, 6:12pm

Thanks again. Gave that a go, but no change. A call with blocked CallerID still displays the "Received incoming SIP connection from unknown peer..." message, while a normal call does not. Similarly, the log messages for the anonymous call look like PJSIP/anonymous-00012d74 instead of PJSIP/VegaPJSIP-00012d70.

I don’t think that the username/IP setting will make a difference (but then again I’m far from an expert), as the call is presented as “[email protected]”?

Stewart1 · January 26, 2020, 6:47pm

Some of these changes require restarting (not just reloading) Asterisk.

If you still have trouble after making IP highest priority, try putting the IP address of the Vega in the Match (Permit) field (and restarting Asterisk).

rymes · January 26, 2020, 7:10pm

Thanks to you @lgaetz and @Stewart1! Changing the order and then executing fwconsole restart seems to have resolved this!

Call me crazy here, but doesn’t it seem like undesirable behavior for the Vega to insert “@anonymous.invalid” into the From: header? Seems like we do know where the call is coming from, just not the user/number, so [email protected] would be more accurate and simultaneously avoid weird problems like this, no?

lgaetz · January 26, 2020, 7:31pm

You’re crazy

The from header is usually set to the identity of the caller, unless you deliberately set it to some other value and use different SIP header(s) to encode the caller’s CID. In this case, it’s not the fact that the From header was set to anonymous that caused the failure, it was the fact that there exists a PJSIP endpoint called ‘anonymous’ generated by FreePBX behind the scenes that was matching the incoming INVITE. The same problem would have occurred if you had a PJSIP extension numbered 90210 and you were receiving calls with a malformed CID of 90210, the inbound call would have matched the extension and would’ve been misrouted as a result.

I assume you have PJSIP extensions, make sure that the change has not negatively affected outbound calls from any PJSIP extensions.

rymes · January 26, 2020, 7:38pm

Thanks, @lgaetz. That does clear it up some, though it still seems weird to me that the hostname would be affected by what the callerID is. [email protected] for a normal call and [email protected] for a blocked call would make a lot more sense to me. Of course, your explanation above means it would have resulted in the same behavior, but still!

Also, it’s possible to modify the user for blocked calls to something other than “anonymous” using the Vega SIP advanced settings, so perhaps it would make sense for the FreePBX Vega setup tool to change this to “Blocked” or something else that would not cause this issue? Thoughts?

lgaetz · January 28, 2020, 8:37pm

Hi Tom:

I think based on what was covered here in this ticket, I would ask that you open a Vega support ticket with the issue and the work around. It may well be that the Vega can be configured to prevent this edge case.

rymes · January 28, 2020, 9:03pm

Lorne,

I’m certain that the Vega can be configured to avoid this, I was thinking that the FreePBX Module used to set up the Vega should be modified to change that setting such that this behavior is not seen.

I’m not certain that I’d call it an edge case, either. Lots of folks block their CallerID (God only knows why, but they do), and we were using the stock configuration of FreePBX PJSIP. Had it not been for customers routinely complaining of receiving errors that our phone lines were disconnected, we’d have never known about this!

Tom

system · February 4, 2020, 9:03pm

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