ASTERISK converting error 503 to error 603


We noticed that ASTERISK is doing SIP Code conversion. During a call, ASTERISK receive error 503 from GSM Gateway but it forwarded error 603 to Genesys (source).

Below is the log from ASTERISK Server (Note: IP Address was changed to a random value)

[Mar 10 17:27:02] VERBOSE[35916] res_pjsip_logger.c: <— Received SIP response (493 bytes) from UDP: —>
SIP/2.0 503 Service Unavailable
Max-Forwards: 70
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPj87870831-c890-4f6b-ad3f-ed4565f8b429
From: sip:09658950326167844041@;tag=2a9a18ee-4060-45c4-a495-85e539cda8e2
To: sip:09658950326@;tag=7c1eb30236e8-19682-a122308
Call-ID: db07712c-28ab-42d2-9b4e-45b86d99c1a3
CSeq: 22733 INVITE
Reason: Q.850;cause=41
User-Agent: 2N SG
Content-Length: 0

[Mar 10 17:27:02] VERBOSE[27298] res_pjsip_logger.c: <— Transmitting SIP response (575 bytes) to UDP: —>
SIP/2.0 603 Decline
Via: SIP/2.0/UDP;rport=5060;received=;branch=z9hG4bK008770E4-45FB-1407-A013-2329480AAA77-11184979
Call-ID: 008770D0-45FB-1407-A013-2329480AAA77-3756922@
From: sip:5100@;tag=008770DA-45FB-1407-A013-2329480AAA77-3794283
To: sip:10609658950326@;tag=e828e793-53dc-4e2c-a660-e3650c24203e
Server: Asterisk PBX 18.6.0
Reason: Q.850;cause=41
Content-Length: 0

There was no conversion from 503 to 603 mentioned in RFC 3261.

Please help in checking why ASTERISK is converting error 503 to error 603.

There is insufficient information here. The dialplan also plays a part in this, and can set the hangup cause and thus control the SIP response code. That has to be examined and understood as well.

Unrelated to this, SIP response codes are not passed through. Conversion happens to/from ISDN cause code meaning that it may not be the same even when unaltered in dialplan.

RFC 3261 does not cover back to back user agents. Asterisk is not a SIP proxy.

Although Asterisk diverges slightly from this, the correct RFC to use is RFC 3398, and you must use forwards and backwards conversions, back to back, to get the overall result.

The default behaviour of chan_pjsip, in this case, is to convert 503 to 42 and 42 back to 503. As such there is another factor in play here.

chan_sip, which will be removed in the next release, can generate 603 in a few more cases, but I think the only one relevant here is when the internal ISDN cause code is unrecognized, and I think the only thing that would cause that when reacting to a failure to start the outgoing leg would be if there were a Reason header, giving a Q.850 cause that isn’t known to Asterisk, or Hangup was called from the diaplan with an invalid code.

In this case, there is such a Reason header and the cause code is 41 (AST_CAUSE_NORMAL_TEMPORARY_FAILURE - short term network problem), which is not one that chan_sip has a rule for, so it will fall back to 603.

Actually, the same fallback for an unrecognized code is also used by chan_pjsip, but one has to go through more hops to find that.

The RFC for preferring the ISDN code in the Reason header is RFC 3326. Although 3398 would actually translate it to 503, not 603.

It is possibly worth noting that 503 is not a helpful error code, as it is basically the code of last resort.

I guess one could make a case that Asterisk should obey RFC 3398, but that would not be because of the incoming 503, but because of the incoming 41.

Thanks David for the detailed explanation. Do you mean that in the next release of ASTERISK, the conversion from error 503 to 603 is expected to be resolved? Is there any plan to to update the ASTERISK hangup cause code to include cause 41 since this cause is listed in RFC 3398 and also defined in ITU-T Q.850?

Hi David, I checked the ASTERISK Hangup Cause Mappings and saw that cause 41 is mapped to error 409. So ASTERISK should have converted the error 503 to error 409 instead of error 603.


No. Some level of conversion of cause codes when both parties are SIP is expected behaviour.

Asterisk knows about cause 41 and will convert SIP 409 to 41, What it doesn’t do is recognize it when generating a SIP cause code.

I have no inside knowledge of the plans, but I doubt that anything will get done unless someone submits an issue, complete with a patch to implement the change, and even then, I imagine it will have very low priority. Even people who work for Sangoma generally will not commit to implementation time scales.

Thanks David. I was expecting ASTERISK to send SIP 409 to Genesys instead of SIP 603 because cause code 41 was found in the ASTERISK Hangup Cause codes. So this is probably a bug that need to be fixed right?

As I originally stated, there is insufficient information to be able to answer that. You’d need to also provide the console output and dialplan. You can write dialplan to do this, or to send a 603, or to send a 404.

Additionally like David says, if such a thing were determined to be a bug there is absolutely no time frame on when it would get looked into.

The RFC 3398 rules, used back to back, do not preserve 409. If 409 where found incoming, it would be converted to 41, but, outbound 3398 says 41 is converted to 503.

I don’t think information is missing, given one assumes that the dialplan takes no active step.

Q.850 41 is being taken from the reason header, rather than the 42 that would be translated from the SIP 503. There is no outgoing cause2sip translation for 41, even though there is a #define for it, so the channel driver applies the default, which is 603.

I’ve been proven wrong on this specific assumption before, so I always like to confirm.

Sorry for my confusion. Did you mean that in ASTERISK, there is no cause2sip translation for 41? Because in RFC3398, there are translations for this. ISDN Cause Code to Status Code Mapping

ISUP Cause value SIP response

41 temporary failure                    503 Service unavailable
42 switching equipment congestion       503 Service unavailable SIP Status Code to ISDN Cause Code Mapping

Response received Cause value in the REL

400 Bad Request 41 Temporary Failure
481 Call/Transaction Does not Exist 41 Temporary Failure
500 Server internal error 41 Temporary failure
503 Service unavailable 41 Temporary failure

Noted on this jcolp. We’ll check if we can update the dialpan to convert SIP 603 (with cause code 41) to SIP 503.

Yes. I’m referring to Asterisk;

chan_sip has similar code but is too big to generate a link to the specific line.

Thanks David

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