cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1249
Views
0
Helpful
1
Replies

CUCM Subscriber to Publisher failover, Outgoing SIP calls Delay

steigja
Level 3
Level 3

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

1 Accepted Solution

Accepted Solutions

Aaron Harrison
VIP Alumni
VIP Alumni

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

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

1 Reply 1

Aaron Harrison
VIP Alumni
VIP Alumni

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

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!