Bridge calls Busy

[boba1120]

Hi all, new issue here with a bridge setup. I have a Master at our main office, and smaller Slave installation at branch. Registration is successful using internal IPs over our Watchguard VPN tunnel. However, any calls to extensions at remote location come up busy. The outbound rule is catching and stripping appropriately.

Here's the Slave log:

13:02:45.366|.\CallLeg.cpp(143)|Log5||CallLeg::onNewCall:[CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.30.207:5060;branch=z9hG4bK-e09983ae
Max-Forwards: 70
Contact: "Karen Brown"<sip:[email protected]:5060>
To: <sip:[email protected]>
From: "Karen Brown"<sip:[email protected]>;tag=7ecc096e67815fb6o0
Call-ID: [email protected]
CSeq: 102 INVITE
Expires: 240
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Proxy-Authorization: Digest username="107",realm="3CXPhoneSystem",nonce="414d535c05f5363502:9d4e97b221da3a9ed6b16a6242d485b5",uri="sip:[email protected]:5060",algorithm=MD5,response="ededfb811e50d2dc445895b1a298ebcd"
Supported: replaces
User-Agent: Cisco/SPA504G-7.5.1a
Content-Length: 0

<br>
13:02:45.375|.\CallCtrl.cpp(346)|Log2||CallCtrl::onIncomingCall:[CM503001]: Call(658): Incoming call from Ext.107 to <sip:[email protected]><br>
13:02:45.376|.\Extension.cpp(1407)|Log3||Extension::printEndpointInfo:[CM505001]: Ext.107: Device info: Device Identified: [Man: Cisco;Mod: SPA Series;Rev: General] Capabilities:[reinvite, replaces, unable-no-sdp, no-recvonly] UserAgent: [Cisco/SPA504G-7.5.1a] PBX contact: [sip:[email protected]:5060]<br>
13:02:45.376|.\CallLeg.cpp(1194)|Log5||CallLeg::setRemoteSdp:Remote SDP is set for legC:658.1<br>
13:02:45.377|.\SLServer.cpp(861)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210000] C:658.1:Offer received. RTP connection: 192.168.30.207:16458(16459)<br>
13:02:45.377|.\CallCtrl.cpp(529)|Log3||CallCtrl::onSelectRouteReq:[CM503010]: Making route(s) to <sip:[email protected]><br>
13:02:45.378|.\CallCtrl.cpp(708)|Log2||CallCtrl::onSelectRouteReq:[CM503004]: Call(658): Route 1: PBXline:114@(Ln.10003@Maserati to Porsche)@[Dev:sip:[email protected]:5060]<br>
13:02:45.424|.\SLServer.cpp(861)|Log5|MediaServer|MediaServerReporting::SetRemoteParty:[MS210006] C:658.2:Offer provided. Connection(by pass mode): 192.168.30.207:16458(16459)<br>
13:02:45.431|.\Target.cpp(441)|Log2||Target::makeOneInvite:[CM503025]: Call(658): Calling PBXline:114@(Ln.10003@Maserati to Porsche)@[Dev:sip:[email protected]:5060]<br>
13:02:45.868|.\CallLeg.cpp(326)|Log2||CallLeg::onFailure:[CM503003]: Call(658): Call to sip:[email protected]:5060 has failed; Cause: 486 Busy Here; warning: Disabled by Forwarding Rule; from IP:172.30.6.240:5060<br>
13:02:45.869|.\Call.cpp(1091)|Log2||Call::RouteFailed:[CM503016]: Call(658): Attempt to reach <sip:[email protected]> failed. Reason: Busy<br>
13:02:45.870|.\Call.cpp(605)|Log2||Call::DoEndCall:[CM503020]: Normal call termination. Reason: Busy<br>

And here's the Master:

13:02:52.692|.\Line.cpp(357)|Log2||LineCfg::getInboundTarget:[CM503012]: Inbound office hours rule (unnamed) for 10003 forwards to DN:101<br>
13:02:52.703|.\CallCtrl.cpp(346)|Log2||CallCtrl::onIncomingCall:[CM503001]: Call(66485): Incoming call from 10003@(Ln.10003@Porsche to Maserati) to <sip:[email protected]:5060;user=endcall><br>
13:02:52.705|.\Line.cpp(1460)|Log2||Line::printEndpointInfo:[CM505004]: Bridge:[Porsche to Maserati] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhoneSystem 10.0.23053.0] PBX contact: [sip:[email protected]:5060]<br>
13:02:52.708|.\CallCtrl.cpp(529)|Log3||CallCtrl::onSelectRouteReq:[CM503010]: Making route(s) to <sip:[email protected]:5060;user=endcall><br>
13:02:52.708|.\Call.cpp(1091)|Log2||Call::RouteFailed:[CM503016]: Call(66485): Attempt to reach <sip:[email protected]:5060;user=endcall> failed. Reason: Busy<br>
13:02:52.708|.\Call.cpp(605)|Log2||Call::DoEndCall:[CM503020]: Normal call termination. Reason: Disabled by Forwarding Rule<br>

I don't know Wireshark that well, but I took a look and it doesn't look like any traffic is heading out to the target extension's IP. Something in the server doesn't seem to want to route the call maybe?

 

[leejor]

Call to sip:[email protected]:5060 has failed; Cause: 486 Busy Here; warning: Disabled by Forwarding Rule; from IP:172.30.6.240:5060<br>

Does 114 have a call forwarding rule that cannot be utilized by the call?

 

[boba1120]

I don't see how, it has a pretty simple "send to mobile" or "send to voicemail". Also this happens with any extension I try.

 

[boba1120]

I should point out, it seems to happen in both directions as well.

 

[boba1120]

UPDATE: Partial workaround, but definitely some odd behavior.

On a whim I adjusted the bridge setting for what to do with a call if the target extension doesn't exist. Originally I had it set to "endcall", which I believe is the default. Interestingly, the text "user=endcall" shows up in the original log. I set it to forward to the reception extension instead, and suddenly bridge calls were able to go through no problem. But in both cases, the target extension definitely existed, and was not busy. Or does "destination" in the text for this setting refer to the server on the other end? Either way, it should never have been invoked, so why does the behavior change?

 

[leejor]

So...if you have the call go to an extension, in the other PBX that has no forwarding set-up at all, does it ring through properly?

 

[boba1120]

Well, the setting in question is on the target server's bridge configuration, in other words the server receiving the call. The text for the setting is:

Configure where calls should be routed during office hours in case the destination targeted does not exist in 3CX Phone Sytem.

Basically it seems that if this is set to End Call then the call always fails, but if it is set to anything else the call does ring through properly. It just doesn't make sense, unless I'm completely misinterpreting what this setting is supposed to do. It would seem that if the "destination targeted" is valid then the call should always go through, and the End Call behavior should not come into play.