Calls fail with a 580 Precondition Failed SIP Message on UC520

Unanswered Question
Jun 16th, 2009

I have noticed some calls that do not go through and the caller on the other end hears nothing. I have been doing SIP tracing, and I found out the following according to the SIP tracing:

  • For calls that fail with a 580 Precondition Failed, either the UC520 does not send the 180 Ringing response after receiving the INVITE message or the SIP packets containing the 180 Ringing response are dropped somewhere
  • The 200 OK response is also not sent when calls fail with a 580 Precondition Failed message
  • For successful calls, both the 180 Ringing and 200 OK responses are sent after receiving the INVITE message
  • In both scenarios, the UC520 does actually send the ACK response

I am unsure whether the UC520 is sending the wrong response, if the problem is actually with the ITSP, or if SIP packets are getting dropped in between the UC520 and the SIP proxy. This problem seems to occur with the 7.0.x and 7.1.x releases.

Has anyone else experienced this problem on the UC520? If so, do you know any solutions to this problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Maulik Shah Tue, 06/16/2009 - 17:18

Can you attach the config (or PM me) & the logs for the failed calls to the thread - typically the 580 error comes about when QoS / RSVP parameters come into play. Did you configure the SIP Trunk via CCA or CLI?

Maulik Shah Tue, 06/16/2009 - 22:31

I saw your traces but either packets are missing in the trace or something else is occuring. Can you gather "deb ccsip message" from the UC520 for a failed call so I can see the exact messages on the UC520 & eliminate the chances of a dropped packet in the network?

Also, your call flow is:

PSTN >> ITSP >> SIP Proxy (which is where you got traces from) >> UC520

Sometimes calls work while other times they do not is what you state - Are all calls going to the voicemail or AA in your testing? Are there other active calls up when you see failures (like at least 2?)

Maulik Shah Thu, 06/18/2009 - 11:46

Going to venture on a wild guess here - but I think you are probably seeing this issue basedon the CAC configuration below:

call threshold interface FastEthernet0/0 int-calls low 1 high 8

What this means is that if you hit the max of 8 active calls - any inbound / outbound SIP calls on the WAN interface (FastEthernet 0/0) would be rejected with a SIP 580 message, this will continue until you hit the low threshold which is 1 active call. My recommendation would be to have the low value at the same value as the high i.e. 8.

John Platts Fri, 06/19/2009 - 11:51

Thanks for pointing that out to me. The Cisco Service Node handshake incorrectly set the low value to 1.

John Platts Fri, 06/19/2009 - 11:52

Does CCA incorrectly set the low value to 1 if it is configured through CCA? Will this be fixed in the next CCA release?

Maulik Shah Fri, 06/19/2009 - 14:39

CCA pushes both high & low to be the same i.e. whatever you put in the max-calls field on the CCA. Did changing the value on low from 1 to 8 fix this?


This Discussion

Related Content