FreePBX | Register | Issues | Wiki | Portal | Support

SIP 404 not found from provider generates 486 busy here to extension


#1

Hi all,

i am trying to understand the behavior of Asterisk/Freepbx when a number is dialed which is not reachable (wrong number) and the responses the SIP Provider sends.

Setup:
Latest FreePBX distro, asterisk 13
1 pjsip trunk, 1 sip extension

Provider A:
is sending after the invite:
SIP/2.0 100 Trying
SIP/2.0 180 Ringing
SIP/2.0 408 Request Timeout

after that FreePBX is doing a
Everyone is busy/congested at this time (1:0/0/1)
Executing [s@macro-dialout-trunk:31] NoOp(“PJSIP/99-00000a3b”, “Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 18”) in new stack

and sends

SIP/2.0 183 Session Progress
Playing 'number-not-answering
Executing [s-NOANSWER@macro-dialout-trunk:4] Congestion(“PJSIP/99-00000a3b”, “20”) in new stack
SIP/2.0 503 Service Unavailable --> to my extension

This is fine.

Provider B:
is sending after the invite:
SIP/2.0 100 Giving a try
SIP/2.0 183 Session Progress
SIP/2.0 404 Not Found

the SIP 404 is than handled by FreePBX with a

Everyone is busy/congested at this time (1:0/0/1)
Executing [s@macro-dialout-trunk:32] NoOp(“PJSIP/299-00038b36”, “Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 1”) in new stack
[s-INVALIDNMBR@macro-dialout-trunk:1] NoOp(“PJSIP/299-00038b36”, “Dial failed due to trunk reporting Address Incomplete - giving up”) in new stack

SIP/2.0 486 Busy Here --> to my extension.

Phones/Applications will log this as a busy phone.

Is there any way to change this behavior after a 404 not found from the provider when dialing a not reachable number so that we dont get a 486: busy here at the extension?
Or has the provider to change his SIP answer?

thank you


(Lorne Gaetz) #2

As you’ve discovered it’s a bit of wild west when it comes to SIP response codes when rejecting calls. I highly doubt you will get the provider to adjust their signalling, you might be able to adjust your congestion messages to suit:
https://wiki.freepbx.org/display/FPG/Route+Congestion+Messages


(Tom Ray) #3

More like discovered what happens with a B2BUA deals with this. @ds_space Understand that Asterisk is a Back-to-Back User Agent. There are TWO channels for this call and your channel isn’t getting a response from the provider, it’s getting a response from the PBX.

You make a call from your phone, it goes to the PBX and the PBX handles it. That is one channel. The call doesn’t have to leave the PBX nor does the call have to go out the PSTN. However, in this case the call is being routed out the PBX to the PSTN (your trunk). So at this point the PBX as started a new channel for this and makes the call to the provider over that.

At this point you have TWO channels on the PBX. If the call is answered, the PBX will bridge those two channels together. If it is not, the PBX-Provider channel is going to get the response from the provider. It will then take that response and translate it to something and send a corresponding result to the other channel. Because the PBX is actually the endpoint for the extension channel. It is what will return the status and errors of that call to the phone.

Again, your phone is not getting a direct reply from the provider. It’s getting a reply that the PBX generated based off what the new created dialed channel got.


#4

thank you.
the route congestion module works fine for tuning the messages played to the caller.

i know that FreePBX is a B2BUA and not a proxy, generating its own sip messages.

Exaclty as you write " It will then take that response and translate it to something "
Is there a way to know what that “something” is and can it be manipulated?

I am thinking of 2 solutions:

  • tell the provider to send another SIP messsage, so that we dont generate a 486 busy here.
  • tell FreePBX to handle the SIP 404 in another way so that it does not send a 486 busy here. i dont know if this is possible?

(system) closed #5

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