Modify SIP return code on asterisk

Hello there,

I am having Asterisk 20.10 running on Ubuntu. Below is the case scenario:

Softphone <—> Asterisk <—> B-side

  1. Call from my softphone dialer rings on the B-side and unanswered. The signaling from B-side to the Asterisk server says “SIP 487 Request terminated” as the return code.

  2. The signaling between Asterisk and my client says “SIP 603 Decline” as the return code.

IS this normal to have 603 shown on my softphone when the actual return code is 487? Can i change this 603 to say SIP 503 on my asterisk to send to the softphone?

Or at least send what is received as SIP 487. ?

Please assist.

The use of 487 is because a CANCEL was sent to cancel the attempt. We sent a CANCEL SIP request, they actually terminate it using a 487.

Asterisk is also not a proxy, so there is no guarantee that response codes are forwarded. If you want control then you can use PJSIPHangup[1] to send back an explicit response code.

[1] PJSIPHangup - Asterisk Documentation

Asterisk is an ISDN PABX with SIP added on. To a first approximation, received SIP codes are translated according to RFC 3398, unless a ISDN reason code is included in a Reason header, in which case that is used. On the other side RFC 3398 is used to translate the ISDN type HANGUPCAUSE code into a SIP status. This process is not one, and I think there are some exceptions.

As it has no end to end meaning 487 has no defined translation, and one would expect the cause code to reflect the underlying reason for the cancel being issued. Relaying 487 would be wrong.

1 Like

Here is an trace of a 487 from the signaling between the asterisk and the B-side

2025/03/21 06:10:23.282064 172.24.21.22:5060 → 172.23.201.166:5060

SIP/2.0 487 Request Terminated

Via: SIP/2.0/UDP 172.23.201.166:5060;branch=z9hG4bKPj33cd5725-ad92-41a5-b21e-2e70dfcdea32;rport=5060

Call-ID: 547c4273-1fcc-426d-a157-e8b552681a48

From: sip:1001@172.23.1.16;tag=0c4648b5-f32d-444d-bed5-f1b495004e1a

To: sip:7785924@172.24.21.22;tag=zjujvjij-CC-1902-OFC-98

CSeq: 15990 INVITE

Warning: 399 172.24.21.22 “SS280000F582L241[00000] Cancel received on initial invite”

Content-Length: 0

Here is the trace of the 603 seen on the same call between the Asterisk and the softphone

2025/03/21 06:10:23.280651 192.168.18.10:5060 → 194.197.192.79:5060

SIP/2.0 603 Decline

Via: SIP/2.0/UDP 194.197.192.79:5060;rport=5060;received=194.197.192.79;branch=z9hG4bK1a0943286a769d06

Call-ID: 1b40860763616c6c000211c1@194.197.192.79

From: sip:1001@194.197.192.79;tag=6ca8fb71702414a2

To: sip:1117785924@194.197.192.99;tag=cc9a3560-ebb8-486d-8263-7be0196f8856

CSeq: 2140 INVITE

Server: Asterisk PBX 20.10.0

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER

Reason: Q.850;cause=16

Content-Length: 0

Looks like normal behavior but is it normal to see a 487 from the B-side not seen as a 487 as is ? Instead seeing a 603 decline (Cause code=16) - normal call clearing.

Yes. That’s how SIP works in regards to 487.

But one more observation is that we recently upgraded our asterisk from version 16 to version 20 and also moved from chan_sip to pjsip. With the previous version, we never had complaints about this issue.

But, only now we are getting complaints about seeing a 603 and they want a 487 as is. Could this be due to the newer Asterisk version as well ?

The behavior would have been the same between chan_sip and chan_pjsip, and across versions.

I notice there is a timeout of 30s set on the dialplan

dialplan:

; — Inbound calls from SBC —

[from-sbc]

exten => _X.,1,NoOp(Incoming call from SBC)

same => n,Dial(PJSIP/${EXTEN:3}@${TRUNK_SIP},30) ; Route to SIP Trunk

same => n,Hangup()

Asterisk CLI output during this test call:
asterisk-marinedo*CLI>

Executing [1117773348@from-sbc:1] NoOp(“PJSIP/sbc_trunk-000004aa”, “Incoming call from SBC”) in new stack

Executing [1117773348@from-sbc:2] Dial(“PJSIP/sbc_trunk-000004aa”, “PJSIP/7773348@sip_trunk,30”) in new stack

Called PJSIP/7773348@sip_trunk

PJSIP/sip_trunk-000004ab is making progress passing it to PJSIP/sbc_trunk-000004aa

Nobody picked up in 30000 ms

Executing [1117773348@from-sbc:3] Hangup(“PJSIP/sbc_trunk-000004aa”, “”) in new stack

== Spawn extension (from-sbc, 1117773348, 3) exited non-zero on ‘PJSIP/sbc_trunk-000004aa’

Can this cause the asterisk to send a 603 to the caller side (softphone dialer) instead of the 487 received from the B-side ?

Can i just not have this 30s timeout value on the dialplan ? Remove it completely?

Yes. Because that is the reason the call failed.

Thank you. I’ve removed that 30s timeout from the dialplan and let the B-side unanswered (that is myself as well) ; So i see

: SIP 480 received from B-side to the asterisk
: SIP 500 ServerInternal Error with Q.850 Cause=127 received from the Asterisk to my softphone.

Why do i see a SIP 500 ?

Q.850 cause code 127, “Interworking, unspecified,” indicates a call disconnect due to an unspecified problem during interworking with a network that doesn’t provide specific cause information.