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