We’ve been working closely with NET’s engineers for the past month providing them with feedback on problems we’ve experienced with SmartSIP and earlier last week, we received the latest version of SmartSIP: 1.0.0.6. I’d have to say I’m very satisfied with NET’s response and the effort they put into addressing the issues we’ve brought up. So hot off the press, we went ahead and installed SmartSIP onto our mediation server and the install went without any issues (I’ll write up another post to show the install sometime in the future).
The one issue we encountered wasn’t much of a product problem with our NET VX1200 and SmartSIP but rather simply not configuring the proper protocol and seeing how it stalled our deployment for half a day, I thought it would be worth writing a blog post about.
Problem
Your OCS, SmartSIP and VX1200 gateway exhibits the following symptoms:
- Snopper with OCS traces reveals the calls are routed back to itself (which is correct) because SmartSIP is designed that way.
- SIP phones to MOC calls work.
- MOC to SIP phones call work.
- All calls routed out to gateway does not work.
You’ve doubled check the settings within SmartSIP ensuring that you’ve set the gateway IP properly:
<sip_realm>10.102.1.5</sip_realm> <!-- <<<< (4) change to the value provided by the ITSP-->
<sip_proxy>10.102.1.5</sip_proxy> <!-- <<<< (5) change to the value provided by the ITSP-->
<sip_expire>180</sip_expire>
<sip_register>false</sip_register> <!-- <<<< (6) set to true or false to use registration based or static ip based authentication as per instructions from the ITSP—>
The live logging sessions in the SmartSIP show traces of:
Failed to load 'SocketData'.
Failed to load 'ChannelHangupComplete'.
Failed to load 'ChannelProgressMedia'.
A SIP trace on the VX1200 shows:
NETVX1200> trace sip
Trace level set to info 2.
[ 2fc][20101206.170126.640:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerInvite: Handling Invite Message as a Challenger
[ 2f8][20101206.170126.640:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerAck: Handling Ack Request
[ 2f8][20101206.170126.640:sip.m0] 1:15:3:1: SIP: (No CSN): SIPChannel::IsChall
engeSuccess: No Subscriber with username [username] in the Subscriber Table
[ 2f8][20101206.170126.640:sip.m0] 1:15:3:1: SIP: (No CSN): SIPChannel::IsChall
engeSuccess: No Subscriber with username [username] in the Subscriber Table
[ 2f8][20101206.170126.640:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerInvite: Handling Invite Message as a Challenger
[ 2fc][20101206.170126.640:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerAck: Handling Ack Request
[ 2fc][20101206.170129.312:sip.i2] CSipAL::SipReceiveOptionsRequest: Responding
at lower level. Will not transport to SIP channel.
[ 2f8][20101206.170139.250:sip.m0] CSipLQMOptionsSession::receiveMessage: OPTIO
NS session with callid 44c720101206170107250@10.102.1.5 will be reset
[ 2f8][20101206.170139.250:sip.m0] CSipLQMOptionsSession::receiveMessage: OPTIO
NS session with callid 400720101206170107250@10.102.1.5 will be reset
[ 2fc][20101206.170143.609:sip.i2] 1:15:3:2: SIP: (No CSN): SIPChannel::HandleC
hallengerInvite: Handling Invite Message as a Challenger
[ 2f8][20101206.170143.625:sip.i2] 1:15:3:2: SIP: (No CSN): SIPChannel::HandleC
hallengerAck: Handling Ack Request
[ 2f8][20101206.170143.625:sip.m0] 1:15:3:2: SIP: (No CSN): SIPChannel::IsChall
engeSuccess: No Subscriber with username [username] in the Subscriber Table
[ 2f8][20101206.170143.625:sip.m0] 1:15:3:2: SIP: (No CSN): SIPChannel::IsChall
engeSuccess: No Subscriber with username [username] in the Subscriber Table
[ 2f8][20101206.170143.625:sip.i2] 1:15:3:2: SIP: (No CSN): SIPChannel::HandleC
hallengerInvite: Handling Invite Message as a Challenger
[ 2fc][20101206.170143.625:sip.i2] 1:15:3:2: SIP: (No CSN): SIPChannel::HandleC
hallengerAck: Handling Ack Request
[ 2f8][20101206.170153.343:sip.m0] CSessionsManager::HandleIncomingSubscribe: E
vent package [message-summary] is not supported in non-proxy like mode. Rejectin
g message with CallID [a21a0cdc-2cfdf8d7-6f13806@10.1.128.80]
[ 2f8][20101206.170153.343:sip.i2] CSipAL::SipSendLowLevelResponse: Responding
at lower level. Will not transport to SIP channel.
[ 2f8][20101206.170158.640:sip.m0] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleR
esetTimeout: Channel was in transitional state for too long. Resetting.
[ 2f8][20101206.170158.640:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::Release
All: Attempting to release and reset channel ... with cause code 0x66, non-Bruta
l, 0x66
[ 2fc][20101206.170159.390:sip.i2] CSipAL::SipReceiveOptionsRequest: Responding
at lower level. Will not transport to SIP channel.
[ 2f8][20101206.170206.234:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerInvite: Handling Invite Message as a Challenger
[ 2fc][20101206.170206.234:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerAck: Handling Ack Request
[ 2fc][20101206.170206.234:sip.m0] 1:15:3:1: SIP: (No CSN): SIPChannel::IsChall
engeSuccess: No Subscriber with username [username] in the Subscriber Table
[ 2fc][20101206.170206.234:sip.m0] 1:15:3:1: SIP: (No CSN): SIPChannel::IsChall
engeSuccess: No Subscriber with username [username] in the Subscriber Table
[ 2fc][20101206.170206.234:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerInvite: Handling Invite Message as a Challenger
[ 2f8][20101206.170206.250:sip.i2] 1:15:3:1: SIP: (No CSN): SIPChannel::HandleC
hallengerAck: Handling Ack Request
[ 2f8][20101206.170208.093:sip.i2] CSipAL::SipReceiveOptionsRequest: Responding
at lower level. Will not transport to SIP channel.
[ 2fc][20101206.170214.250:sip.m0] CSipLQMOptionsSession::receiveMessage: OPTIO
NS session with callid 6e5b20101206170142250@10.102.1.5 will be reset
[ 2fc][20101206.170214.250:sip.m0] CSipLQMOptionsSession::receiveMessage: OPTIO
NS session with callid 65b120101206170142250@10.102.1.5 will be reset
[ 2f8][20101206.170215.625:sip.m0] 1:15:3:2: SIP: (No CSN): SIPChannel::HandleR
esetTimeout: Channel was in transitional state for too long. Resetting.
[ 2f8][20101206.170215.625:sip.i2] 1:15:3:2: SIP: (No CSN): SIPChannel::Release
All: Attempting to release and reset channel ... with cause code 0x66, non-Bruta
l, 0x66
NETVX1200>
After troubleshooting for half a day and not really making any progress, I went ahead and reached out to NET to get their engineers on it. What was nice was that NET ended up getting 1 engineer for the VX and another one for SmartSIP which were very knowledgeable with their products so after troubleshooting for about an hour, we finally figured out what the problem was.
Solution
What the NET SmartSIP engineer noticed was that the wireshark captures exhibit the following:
Status: 401 Authentication Required
Seeing how this almost seemed like a the gateway was challenging the SmartSIP service trying to send the call out, we went and reviewed the trunk groups again:
As shown in the screenshot, the trunk group we felt was supposed to handle the calls was the OCS trunk group. However, through the traces and testing we did, it looked like the calls were hitting trunk group ThinkTel because that was the only one that would challenge for authentication when a call was routed to it.
So we’re here scratching our heads as to why this was happening. The VX engineer then suggested that we do a log capture on the gateway then parse through it line by line to see what exactly was going on. After going offline for 30 minutes, the engineer came back and told us that the logs were showing that packets were sent via UDP and not our expected TCP. As many OCS administrators would know, OCS is TCP or TLS only and we had configured that trunk group as TCP. We relayed this information back over to the SmartSIP engineer and he told us SmartSIP defaults to UDP.
So what did we do? We checked UDP to see if things would change and it did!
While this was a valid workaround solution, I have since added in my notes to ask NET how we can configure SmartSIP to send traffic via UDP. Once I get that information, I’ll go ahead and update this post.
No comments:
Post a Comment