Showing results for 
Search instead for 
Did you mean: 

7945 shows "pending" for calling party name on incoming calls.

Gateway is SIP with pri ni2 to pstn. Debug isdn q931 shows calling party name coming in correctly from telco, just does not get to phone.


In CallManager gateway is Device > Trunk (SIP)

Callmanager 8.0.3a with IOS 15.1.2.T, SIP Phone Load 9.0.3

Cisco Employee


Does it display the correct number after answering the call? There was an issue when sendin the calling id on the FACILITY Message.  If the calling name comes in the initial SETUP message, in this case it would be a FACILITY IE in the SETUP (not after the SETUP) it worked, can you please verify.

Also check if the phone is part of a hunt group. You can check these bugs too:

CSCsi06623    Calling party name is not obtained when it comes in ISDN Facility messag
CSCta13489     no caller id name when call comes in to hunt group




Regards, Tere. If you find this post helpful, please rate! :)

Funny...I keep running into this same post every several months....

Had the same issue again.  This time neither option fixed my problem.  I did a bit of fiddling and found the following:

1. delay between initial PRI message and subsequent calling name facilitiy message was 688ms.

Initial PRI message: 23:05:24.395
Delayed calling name message: 23:05:25.083

2. I changed the timers value to 900 which allowed the name to come through and then started reducing it till it showed pending.  When I tried 800 it failed.  Set it to 850 and it seemed to work consistently.

 timers buffer-invite 850

3. I also applied the asserted-id setting below before fiddling with the timer value.

dial-peer voice 100 voip
 description Inbound FROM PSTN:Call leg CUBE--->CUCM
 no voice-class sip asserted-id

Happy SIPping...


I run into this post as well from time to time.  Those in the future might understand better with a different description.


Caller ID Name display shows "pending", Caller ID Number is correct.

Workaround: put the caller on hold.  once resumed the display is corrected.

PRI -> CUBE 15.5(3)M4a -> SIP -> CUCM 10.5



The ISDN provider sends the Caller ID Name into the gateway as an Facility IE message seperate from the initial setup message.  In this case the gateway is sending UCM a SIP Invite before receiving the ISDN Facility IE message.  To fix this delay the gateway from sending the SIP Invite until after the ISDN Facility IE message by using the  "timers buffer-invite" command.  Calculate the delay by subtracting the Setup time from the Facility time.


Debugs enabled: debug isdn q931, debug ccsip messages


In my situation initially the ISDN Setup message came in and immediately after the CUBE would send a SIP Invite to the CUCM.  Since it doesn't have a name to send it inserts "pending"in the Remote-Party-ID: field of this SIP Invite.  Later (480 ms later) the ISDN provider would send a Facility message with the Caller ID Name.  CUBE would generate an Info message to CUCM which CUCM returned SIP/2.0 400 Bad Request.  At this point the name display on the IP phone says pending.


I needed to calculate the time difference between when the ISDN Setup message came in and the ISDN Facility message came in.  The math worked out to 480 ms in this case, consistantly.


Then I asked the CUBE to wait 600 ms once it receives an ISDN Setup message before sending a SIP Invite message with this command.

 timers buffer-invite 600



My VOIP dial-peer pointing towards CUCM has this command added as well.


dial-peer voice 100 voip
 description Inbound FROM PSTN:Call leg CUBE--->CUCM
 no voice-class sip asserted-id



The research I did lead me to believe this should only appear with PRI providers sending Caller ID Name as a seperate message and SIP between the CUBE and CUCM.  If the PRI provider sent the Caller ID Name along with the initial ISDN Setup message (aka Display) this would be fine.  Also if the gateway was configured with H.323 between itself and CUCM this would be fine.



Did you ever get resolution on this? I seem to be running into the same problem.


Adding this fixed it.

1. enable

2. configure terminal

3. sip-ua

4. timers buffer-invite

5. exit


Nice work Jason...I just used this for the same problem and it fixed it. 

timers buffer-invite 500


I just had another deployment where this 'sip-ua timers' fix did NOT resolve the issue.  I was able to fix it by also applying the "no voice-class sip asserted-id" command under the dial-peers that point to CUCM.


Hello Steve! ... I know this is an old post but thought I'd give it a shot!

I also had the same problem and timers did not fix... I applied your suggested command "no voice-class sip asserted-id" and corrected the problem... so THANKS for that!

However, I was wondering if there is another way to correct? maybe within the sip config under voice service?


Content for Community-Ad