Response with 603 Decline to trunk

Hi Support,

I have just set my 1st PBX, and works almost as I want.

However, I faced a small issue:
I use an external trunk. If a call comes from the trunk and accepted, works fine. But, if the client refuses the call while ringing (declines), the trunk will continue to call.

After some investigations, found something:

  • Once the client declines, the sip phone sends a ‘603 Decline’ message to the PBX

  • After then, the PBX will send a User Busy message to the other client and the call terminates normally.

  • BUT, since the other client is a PBX server (trunk), it expects a ‘603’, as iit treats my PBX as a client, but receives a User Busy from my server.

My opinion is, that the above conflict causes the trunk to continue calling.

I trie to send a decline message using ‘Hangup(603)’ but it did not solved the issue. Seems like the message sent to the trunk is ‘603 Delcined’, while the trunk expects ‘603 Decline’.
Guess the former is a result and the latter is a command.

I would like to know how to respond to the trunk the way it expects.

BTW. tested the trunk with a sip client, and it could decline the call as expected.

Thanks for your help.

There is no real distinction between trunks and extensions in SIP.

Asterisk translates SIP codes to ISDN codes and then, if the incoming side is also SIP, back again. That will lose information.

With the latest versions, you can explicitly read the SIP code. If there is an ISDN code that officially translates to SIP 603, you could then set that ISDN code in an explicit Hangup call. There is an RFC that lists the translations, or you could look at the source code.

Hangup uses ISDN cause codes, not SIP ones.

I think you will find that the handling of reject doesn’t meet your ideals on commercial, SIP capable, PABXes, either.

david55, thanks for your help.

Unfortunately, I am new to SIP, and do not clearly understand your answer.

Q: can aserisk response with SIP cause instead of ISDN ones, as you proposed?

I dont want to mess up with source code. This is just a small issue, but I thougth other people may have met this problem before, as trunks are used quire occasitionally.

If somebody have an idea of what to adjust in the configuration or what rules to use in the extension handling, I would appreciate.


Firstly 603 is a retryable failure and its use is suggested for people who don’t want callers to be able to tell whether they are busy on another call or just don’t want to take the call at that time.

My detailed knowledge relates to a version of Asterisk that is getting a bit out of date, but that doesn’t support any mechanism for forcing particular technology specific status codes.

As far as I can tell, 603, should actually translate to 403, which is actually not retryable. However, it does get marked as busy as well, in terms of generating DIALSTATUS. I may have missed somewhere where the ISDN cause of call rejected gets overwritten with busy, or it is possible that a subsequent change has produced that result. In the latter case, it is possible that there is a regression bug, but without more careful reading of the code, I can’t be sure that this is supposed to be a special case.

Certain things, in particular using & in the Dial application parameters, or pussibly the explicit use of the Busy() application, may override the original hangupcause.

Asterisk is a back to back user agent that tries to provide a common abstraction to all technologies, and that abstraction is based on ISDN, not on SIP.

The ability to find out the incoming technology specific status code is new, and people on this forum often use obsolete versions of Asterisk, so you need to tell us which version you are using.

Thanks, david55

However, I still have no idea, what to do. Looks like an issue in the other side of the trunk (the public PBX).

However, if i disconnect my PBX and connect to the public PBX, using LinPhone, upon pressing the No button at ringing, the caller sees the Busy message immediately. That is, the PBX will not retry to call.

Maybe I was confusing, so clear: once I refuse the call, my PBX disconnects the trunk. Once the connection is terminated, the trunk will recall my PBX immediately, so it looks like a new inbound call, while the other client constantly sees ringing. This recall does not happen if I test the public PBX with a SIP client.

I do not want to mess up the forum with pasting logs, please tell me if you need.