Anonymous/Withheld PSTN calls: endpoint won't hangup

FreePBX Endpoints
1

I’ve came accross an unusual scenario. If an Anonymous caller makes an call via the PSTN (via SPA232D gateway), and the SIP endpoint/reciever, not the PSTN caller, later rejects the call, Asterisk/FreePBX keeps the channel connected. This does not happen for anonymous calls from a SIP trunk (i.e. Sipgate).

If the PSTN caller calls with their caller ID, Freepbx cuts the line.

I’ve analysed the difference between the SIP headers, and the “From” header is different. Instead of [“pstn number” <sip:[email protected]...>], it sends [“Withheld” <sip:192.168...>]

I tried adding a custom dialplan that checks for “Withheld” and swaps it for the pstn number, and sets the caller ID (in the from header above) as anonymous. This is the same as the sip from header with the sipgate trunk which works. Sadly this change makes no difference and the line still will not cut from the recieving endpoint side if the caller is anonymous.

I would appreciate any advice, if anyone has came accross this previously. It seems it has something to do with freepbx not being able to close the channel for some reason, associated with possibly the sip headers.

2

Please paste the Asterisk log for a failing call, with pjsip logger turned on, at pastebin.com and post the link here.

3

@Stewart1

This was an incoming test call from anonymous/withheld through PSTN Gateway SPA232D. No incoming route has been set so this gets caught by the catchall context. The “this number is not in service” message is played and the Hangup() function is executed as per the log, but the channel between the gateway and freepbx remains open (as the PSTN FXO light remains flashing).

As mentioned previously, the channel successfully disconnects if the caller does not hide their ID.

Please ignore the Sipgate SIP headers. Only 192.168.0.130 is the PSTN gateway.

4

According to the SIP trace a BYE was sent, but the gateway rejected it for some reason thinking that there was no call or transaction. Looking at all the tags and Call-ID in the BYE in comparison to prior messages shows them to be correct. My gut says it is some weird quirk of the gateway’s SIP implementation that isn’t to spec.

5

@jcolp

This is what happens when there is a caller ID. It sends the number back along with the “BYE” before the @192.168.0.130, but it doesn’t when there isn’t any ID.

Could this be part of the reason?

6

That’s a gateway question, why it is doing what it is doing, and I don’t know. From a SIP perspective they’re really equivalent.

7

I’ve finally managed to solve the issue, it’s because there needs to be a User ID set in the Voice->>PSTN page, regardless of whether there is any authentication set up. That strangely affects the ‘From’ header, so that when the caller ID is witheld, it shows as [userId]@[ip address].

Thought this might be useful if anyone else comes across this issue with their SPA232D or other Cisco PSTN Gateways.

8

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