cucm --sip-- cube --sip ---pstn SIP/2.0 500 Internal Server Error

[NBRK_Cisco]

Hi all

please I need help.

cucm11.5 --sip-- cube2921 --sip --- pstn

when calling from CUCM internal phones some call disconnected with  SIP/2.0 500 Internal Server Error

and some another calls are good

sh run and debug ccsip mess incuded

[Jonathan Unger · Accepted solution]

Hi There,

CUBE is sending a 183 Session Progress with SDP message back to CUCM, but CUCM does not respond to the message. It would be interesting to see what happens if you enable "PRACK" on the SIP profile applied to the SIP trunk in CUCM.

On CUCM, adjust the setting in the SIP profile applied to the SIP trunk called "SIP Rel1XX Options" to "Send PRACK if 1xx Contains SDP". After saving the SIP profile, reset the trunk (careful, this will drop any active calls).

Let us know the result after you have made this change!

- Jon

[NBRK_Cisco]

Thank you a lot.

I have several branches with the same config.

and in all branches everithing is ok exept one branch.

[Jonathan Unger]

I would still suggest trying what I have mentioned above on the CUCM SIP trunk to the VGW which is experiencing the issue.

After you make the change to the SIP profile and reset the trunk, try the call again and see what happens. You can also take another debug ccsip messages from the gateway and post it here if the call fails.

[NBRK_Cisco]

in another branch error like the same

when calling to PSTN one call is good another is fast bysi

debugs included

[Jonathan Unger]

Thanks for posting the follow up output. I am sorry to hear that you are still experiencing an issue.

The most siginificant difference I noticed between the calls was that on the non-working call, the PSTN sent a 180 Ringing with SDP to the CUBE. On the working call the PSTN sent a 183 Session Progress with SDP to the CUBE instead (right click and view image to actually read it).

Would you be able to add the line "voice iec syslog" to your config? It can help generate useful log messages when there are call failures.

Additionally, would you be able to run another failed call and collect the following debugs?

debug ccsip messages
debug ccsip error
debug voip ccapi inout

Finally, random question. Is 10.18.26.3 another CUCM node? Strangely enough in both failed calls that was the media address negotiated on the inside, on the working call the media address negotiated was 10.18.26.2. This isn't necessarily related to the issue, but I am curious nonetheless.

[NBRK_Cisco]

Thank you Jonathan for your efforts.

I opened TAC case and Ishan Zutshi resolved case.

He added to your solution also on CUBE

sip

  rel1xx supported “100rel”

[Jonathan Unger]

Thanks for following up on this thread with your solution!

[NBRK_Cisco]

I copyed existing sip profile and edited as you told

but without success

[fpavicic]

Thanks guys 5*.