cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3476
Views
0
Helpful
2
Replies

CUCM 8.0.3.20000-2 SIP2SIP via CUBE SIP/2.0 486 Busy here

Hello,

I'm getting a SIP message "SIP/2.0 486 Busy here" on certain calls to the PSTN.   My setup is:

CUCM-----SIP---->CUBE----SIP---->PSTN

On the SIP debugs, I see the call being setup:

Received:
INVITE sip:<<called #>>@<<CUBE IP>>:5060 SIP/2.0

Via: SIP/2.0/TCP <<CUCM IP>>:5060;branch=z9hG4bK1990221d77155

From: "Username" <sip:<<Callingmask>>@<<CUCM IP>;tag=78137dd5-bc47-4d7e-a0e9-6cb62473afe3-36206511

To: <sip:called#@<<CUBE IP>>>

Date: Thu, 05 May 2011 18:33:03 GMT

About half a second later, I see the following:

Sent:
SIP/2.0 486 Busy here

Via: SIP/2.0/TCP <<CUCM IP>>:5060;branch=z9hG4bK1990221d77155

From: "Username" <sip:<<cCallingmask>>@<<CUCM IP>>>;tag=78137dd5-bc47-4d7e-a0e9-6cb62473afe3-36206511

To: <sip:<<called#>>@<<CUBE IP>>>;tag=316F7F01-24C8

Date: Thu, 05 May 2011 11:34:14 GMT

I understand what the 486 Busy here message means.   What I'm having trouble understanding is who is initiating this message.   It looks to me like it is CUCM sending the "Busy here" message but I don't understand why it shows up as a sent message instead of a recieved message on CUBE.   Am I reading this debug wrong and the "Busy here" message is coming from the PSTN?

Any clues as to where to look to correct?

Thanks,

Glenn

2 Replies 2

jtesar
Level 1
Level 1

Hi Glenn,

For this call flow, there should be two call-ids.  The leg between CM and CUBE and between CUBE and the PSTN.  You can follow each leg via the Call-ID.

If CM originates this call towards CUBE, then any 486 sent from CUBE would be towards CM in response to this INVITE, as the CUBE to PSTN leg would receive the 486.  Section 3.9 Unsuccessful Busy of the following document shows a sample call flow with a 486 response:

http://www.rfc-editor.org/rfc/rfc3665.txt

   Alice           Proxy 1          Proxy 2            Bob
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|   INVITE F2    |                |
     |     100  F3    |--------------->|   INVITE F4    |
     |<---------------|     100  F5    |--------------->|
     |                |<---------------|                |
     |                |                |      486 F6    |
     |                |                |<---------------|
     |                |                |     ACK F7     |
     |                |      486 F8    |--------------->|
     |                |<---------------|                |
     |                |      ACK F9    |                |
     |     486 F10    |--------------->|                |
     |<---------------|                |                |
     |     ACK F11    |                |                |
     |--------------->|                |                |
     |                |                |                |

-jt

hemurray
Cisco Employee
Cisco Employee

Run following debugs:

debug ccisp messages

debug voip ccapi inout

This will provide the SIP message details and verify your dial-peer matching for inbound and outbound.

I will assume the Call-ID for the partial messages are the same, thus suggesting the CUBE SENT the 486.

Need to look at SIP messaging between the CUBE and ITSP to see what messaging occurred.

Please upload the debugs if you need further guidance.

Also, for in depth sip details, run debug ccsip all.

Be sure to configure router so debugs have minimum impact on the devices resources if you do.

Henry