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?
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.
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.