cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3222
Views
10
Helpful
7
Replies

SIP Trunk Redundancy

mightyking
Level 6
Level 6

Hello Everyone,

The calls to the primary SBC provided by our SIP Trunk provider works with no issue. However, the same calls fail when they are sent to the secondary SBC. We are testing the failover and would like to send the call to the secondary SBC.

 

I can see in the logs that the call tries the secandary SBC (dial-peer 208) first but fails then it goes to the primary SBC (dial-peer 201).

 

The show dialplan number 5146027093 shows the correct dial-peer 208  but the call goes through

dial-peer 201.

 

sbc1#show dialplan number 5146027093
Macro Exp.: 5146027093

VoiceOverIpPeer208
        peer type = voice, system default peer = FALSE, information type = voice,
        description = `WAN Outgoing local Calls to Bell',
        tag = 208, destination-pattern = `[2-9]..[2-9]......$',
        voice reg type = 0, corresponding tag = 0,
        allow watch = FALSE
        answer-address = `', preference=0,
        CLID Restriction = None
        CLID Network Number = `'
        CLID Second Number sent
        CLID Override RDNIS = disabled,
        rtp-ssrc mux = system
        source carrier-id = `', target carrier-id = `',
        source trunk-group-label = `',  target trunk-group-label = `',
        numbering Type = `unknown'
        group = 208, Admin state is up, Operation state is up,
        incoming called-number = `',
connections/maximum = 0/unlimited,
        bandwidth/maximum = 0/unlimited,
        DTMF Relay = enabled,
        modem transport = system,
        URI classes:

 

Please find attached the output of the debug ccsip messages. I am also attaching the config of the voice Gateway.

 

 

 

Thanks in advance for your help,

 

MK

3 Accepted Solutions

Accepted Solutions

Are you sending your invite using the correct source ip. I see your cube is sending 5 invites without response. This was to siptrunking.bell.ca on port 50505. Assuming the destination is correct and the non standard port is agreed with vendor I don't see anything other than source IP from your end. Otherwise its provider problem.

View solution in original post

Just as Mohammed mentioned, you need to verify that you can connect to the second SBC using the source IP address and port you are using... 

From the logs your ITSP is not responding to your INVITE..  If the IP address 192.297.235.179 has IP connectivity to the sbc address 207.236.202

114, then open a case with your ITSP. Find out why they are not responding to your request 

//2037844/5C5391000000/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:5146027093@207.236.202.114:50505 SIP/2.0
Via: SIP/2.0/UDP 192.197.135.179:5060

 

Please rate all useful posts

View solution in original post

Great news. Plz remember to mark the post as answered 

View solution in original post

7 Replies 7

BradEast1
Level 3
Level 3

Looks like you're receiving a 401 unauthorized message:

 

Dec 21 21:26:16.556: //2014989/90A84E000000/SIP/Msg/ccsipDisplayMsg:

Received: 

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.197.135.179:5060;branch=z9hG4bK55019C6

From: "SIP Trunk Test Phone1" <sip:6132604850@lab.internetvoice.ca>;tag=E53268E1-1F7F

To: <sip:5146027093@siptrunking.bell.ca>;tag=1388338748-1513891414956

Call-ID: 6990DBED-E5CC11E7-8429AA3A-F9B0233F@lab.internetvoice.ca

CSeq: 101 INVITE

Timestamp: 1513891576

WWW-Authenticate: DIGEST qop="auth",nonce="BroadWorksXjbgzuzscTe2tn8gBW",realm="siptrunking.bell.ca",algorithm=MD5

Content-Length: 0

 

Hi BradEast1,

Thank you for replying. The 401 unauthorized message is when the call has already failed to go through the secondary SBC (202.114) and trying to go through the primary  (237.219) and it is normal to receive that message because the provider is challenging and requesting the identification one more time. As you can see after that message the call goes through correctely. The provider stated that we You will not get a 401 challenge when hitting the secondary SBC (202.114).

 

I tried to remove the voice-class sip profile from the dial-peer 208 but that did'nt help either.

 

any ideas?

 

Thanks,

 

MK

 

 

 

 

 

 

 

 

Are you sending your invite using the correct source ip. I see your cube is sending 5 invites without response. This was to siptrunking.bell.ca on port 50505. Assuming the destination is correct and the non standard port is agreed with vendor I don't see anything other than source IP from your end. Otherwise its provider problem.

Hi Mohammad

I don't understand what you mean by source addresse! Nothing has changed in the VG configuration other than giving a higher priority to the dial-peer 208 which points to the secondary SBC.

 

I removed the voice class sip profile from the dial-peer 208 and shutdown the dial-peer 201 to force the call to go the secondary SBC but hear a busy tone. Please find attached the new debug.

 

Thanks,

 

MK

Just as Mohammed mentioned, you need to verify that you can connect to the second SBC using the source IP address and port you are using... 

From the logs your ITSP is not responding to your INVITE..  If the IP address 192.297.235.179 has IP connectivity to the sbc address 207.236.202

114, then open a case with your ITSP. Find out why they are not responding to your request 

//2037844/5C5391000000/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:5146027093@207.236.202.114:50505 SIP/2.0
Via: SIP/2.0/UDP 192.197.135.179:5060

 

Please rate all useful posts

Thank you both for taking the time and replying.

The issue was the port 50505 which was being blocked by our FW.

 

Regards,

 

MK

Great news. Plz remember to mark the post as answered