CUCM Subscriber to Publisher failover, Outgoing SIP calls Delay

Answered Question
Mar 17th, 2010
User Badges:

Hello All,


             I'a, having an issue with a new CUCM installation using a SIP trunk for outside calling,  My setup is CUCM 7.1.3 with a publisher and a subscriber.  The subscriber is located in the same site as the CUBE and the publisher is at a remote site across a private fiber.  What the issue is is when I shut down the port to the subscriber all phone fail over to the subscriber as they should and all internal and incoming sip external calls complete fine.  However for about 3 minutes I can't make a successfull outside call.  I call my cell phone and the cell phone rings but when I answer the cell phone it does terminate the call on the CUCM side, so I still hear ringing on the 7941 for instance.  This clears after 3 minutes.  I have an ASA in between the CUCM and CUBEand I was doing a fixup on sip and sccp.  I remove the sccp fixup and sip fixup and instead allowed every tcp and udp connection from my internal CUBE interface to all voice vlans internally behind the ASA  This did not fix the problem.  What should I looking for to fix this issue?  My CUBE has the subscriber for internal calls on the sip dial-peer as preference 1 and the publisher as preference 2.  So I'am doing sip from the CUCM to the CUBE.  As anyone ran into  this issue?  thanks


I will also sometimes get a busy signal calling outbound for a short amount of time during the failover, is this expected?  Thanks


The other issue I see is that the firewall keeps showing CUBE traffic to the subscriber and not the publisher, is my preference incorrect on the CUBE, should I make them equal?  Thanks

Correct Answer by Aaron Harrison about 7 years 4 months ago

Hi


I would probably do a packet capture outside the CUBE, and one inside the CUBE during the 3 minute period... This will allow you to verify that the SIP messages are coming back to the CUBE, and then where they are sent from the CUBE. Perhaps even leave it running for past the 3 minutes, so you can see what changes when you do second test call after the 3 minutes...


Aaron

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Aaron Harrison Wed, 03/17/2010 - 10:15
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

Hi


I would probably do a packet capture outside the CUBE, and one inside the CUBE during the 3 minute period... This will allow you to verify that the SIP messages are coming back to the CUBE, and then where they are sent from the CUBE. Perhaps even leave it running for past the 3 minutes, so you can see what changes when you do second test call after the 3 minutes...


Aaron

Actions

This Discussion