Cisco ext 6923243 calls Avaya ext 6500071 which has activated a call fwd busy don’t answer to Cisco ext 6923240. Call is not forwarded to Cisco ext 6923240 as CM sends "500 Server Internal Error (Application cleared call)"
The traces do not reveal any particular proc error or denial event, simply after CM creating the 2nd calleg to forward the call it will soon throw "500 Server Internal Error (Application cleared call)".
The 500 server internal error is fired on the original incoming call ie on the 1st calleg. If looking at that only, we end up with the below interaction:
9336 14:30:02.013 SIP In INVITE 1547 6923243 6500071 >>>>>> no SDP
9338 14:30:02.014 SIP Out 100 1547 6923243 6500071
9601 14:30:02.125 SIP Out 180 1547 6923243 6500071 10.16.31.210 >>>>>>>>>>>> with SDP offer
41679 14:30:17.036 SIP Out 181 1547 6923243 6500071 10.16.31.210 >>>>>>>>>>>> with SDP offer
41801 14:30:17.049 SIP Out 183 1547 6923243 6500071 10.16.31.210 >>>>>>>>>>>> with SDP offer
41932 14:30:17.206 SIP Out 180 1547 6923243 6500071 10.16.31.210 >>>>>>>>>>>> with SDP offer
41943 14:30:17.248 SIP In PRACK 1547 6923243 6500071 >>>>>> no SDP
41944 14:30:17.249 SIP Out 500 1547 6923243 6500071 <<<< "500 Server Internal Error (Application cleared call)"
41945 14:30:17.251 SIP In ACK 1547 6923243 6500071
That is no SDP answer in the incoming PRACK and this scenario actually seems to match what is described in section 5 of RFC 3262:
If the UAC receives a reliable provisional response with an offer
(this would occur if the UAC sent an INVITE without an offer, in
which case the first reliable provisional response will contain the
offer), it MUST generate an answer in the PRACK. If the UAC receives
a reliable provisional response with an answer, it MAY generate an
additional offer in the PRACK. If the UAS receives a PRACK with an
offer, it MUST place the answer in the 2xx to the PRACK.
and in that case it is not compliant with the above, hence CM drops the call with 500 server internal error.
