Force CID stopped working with new server

Found something wrong ?
ronf
Posts: 6
Joined: Mon Jun 18, 2012 5:24 pm

Force CID stopped working with new server

Post by ronf » Tue Jun 26, 2012 10:31 pm

When the new server switched over in June 2012, the FORCE CID command stopped working as it used to. I use this to route calls in Trixbox. Command is: when "444401" then sys.Dial("1310XXXXXXX@sip-in.les.net[fu=1234567,fd=1234567]. I've tried fu=, fd= & fh= in various combinations but issue persists. The odd thing is that the CID reports being changed, yet the CID fails to route the inbound call (it worked fine before). From REPORTS: 1234567 "1234567" <1234567> s ANSWERED. This CID should have routed to a local exten, NOT to "s" . However CIDs that are NOT forced still do route correctly to an extn. Any fix or work around would greatly be appreciated.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Force CID stopped working with new server

Post by Aaron » Wed Jun 27, 2012 10:32 am

Is it possible there is some configuration setting at your provider, les.net, that could be tying the ability to set caller ID to the specific IP address the call came from?

I'm thinking that maybe les.net have a setting on your account that allows custom caller ID to be set from the old sipsorcery IP address of 69.59.142.213 but not from the new address of 67.222.131.147.

There's not a lot involved in setting the caller ID as far as the sipsorcery end is concerned it merely tweaks the From header on the outgoing call request. As such there's not a lot that can go wrong and I'm pretty sure it's all still working normally.

ronf
Posts: 6
Joined: Mon Jun 18, 2012 5:24 pm

Re: Force CID stopped working with new server

Post by ronf » Wed Jun 27, 2012 9:54 pm

I see now that the commands for Incoming Call Forwards are being modified by the the ELSE statement whether or not I use the fu= command. I also tried to send the call to CallCentric, but it was sent to the ELSE statement (Les.net) as well. Are both the FORWARD and ELSE commands set up correctly (though somehow they worked fine before the server changeover)?

WITH NO fu= COMMAND:
# Incoming Calls
sys.Log("Incoming call to #{req.URI.User}.")

case req.URI.User

# Call forwards.

when "444401" then sys.Dial("902779@sip.sipsorcery.com")

else sys.Dial("1310XXXXXXX@sip-in.les.net[fd=33445566]") # FWD OK, DTMF OK.
end

end

RESULT: SIP/1155XX... 444401 "33445566" <444401> NOTE:1155XX is Les.net
PLEASE NOTE THAT THE CALL GOES TO LES.NET, NOT TO SIPSORCERY as it should have (whether I use @sip.sipsorcery.com, or just @sipsorcery.com)!

WHEN THE fu= AND/OR THE fd= COMMAND IS ADDED:
# Incoming Calls
sys.Log("Incoming call to #{req.URI.User}.")

case req.URI.User

# Call forwards.

when "444401" then sys.Dial("902773@sipsorcery.com[fu=234567,fd=234567]")

else sys.Dial("1310XXXXXXX@sip-in.les.net[fd=33445566]") # FWD OK, DTMF OK.
end

end

RESULT: SIP/1155XX... 234567 "33445566" <234567> NOTE:1155XX is Les.net

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Force CID stopped working with new server

Post by Aaron » Fri Jun 29, 2012 11:04 am

It's a little bit tough to work out what's happening. Can you post up a trace from a call? You can get one from the Siverlight portal http://www.sipsorcery.com/mainsite/Home/Portal and choose the Console menu option.

ronf
Posts: 6
Joined: Mon Jun 18, 2012 5:24 pm

Re: Force CID stopped working with new server

Post by ronf » Fri Jun 29, 2012 12:33 pm

Aaron, thank you for showing me how to get this log and for your help. I changed the below fu= & fd= (for 444401) to 234567 so as to be consistent with my last post.

NATKeepAlive 12:14:51:635 sip1(10252): Requesting NAT keep-alive from proxy socket udp:67.222.131.147:5060 to udp:72.67.24.28:51847.
DialPlan 12:14:53:901 sip1(3840): Using dialplan callSXM for In call to sip:444401@sipsorcery.com.
NewCall 12:14:53:901 sip1(3840): Executing script dial plan for call to 444401.
DialPlan 12:14:53:932 sip1(3840): Incoming call to 444401.
DialPlan 12:14:53:932 sip1(3840): Commencing Dial with: 902779@sipsorcery.com[fu=234567,fd=234567].
DialPlan 12:14:53:932 sip1(3840): Call leg is for local domain forwarding to incoming dialplan for 902779@sipsorcery.com.
DialPlan 12:14:53:932 sip1(3840): ForkCall commencing call leg to sip:902779@sipsorcery.com.
DialPlan 12:14:53:932 sip1(3840): Creating B2B call for sip:902779@sipsorcery.com.
DialPlan 12:14:53:948 sip1(3840): Using dialplan 902XXX PLAN for In call to sip:902779@sipsorcery.com.
NewCall 12:14:53:948 sip1(3840): Executing script dial plan for call to 902779.
DialPlan 12:14:53:979 sip1(3840): Incoming call to 902779.
DialPlan 12:14:53:979 sip1(3840): Commencing Dial with: 13102948XXX@sip-in.les.net[fd=33445566].
DialPlan 12:14:53:994 sip1(3840): Attempting to locate a provider for call leg: sip:13102948XXX@sip-in.les.net.
DialPlan 12:14:53:994 sip1(3840): ForkCall commencing call leg to sip:13102948XXX@sip-in.les.net.
DialPlan 12:14:53:994 sip1(3840): Switching to sip:13102948XXX@sip-in.les.net:5060 via udp:67.222.131.147:5060.
DialPlan 12:14:53:994 sip1(3840): SDP on UAC call had public IP not mangled, RTP socket 66.54.140.46:20682.
DialPlan 12:14:54:854 sip1(3840): Information response 100 Trying for sip:13102948XXX@sip-in.les.net.
DialPlan 12:14:55:494 sip1(3840): Response 200 OK for sip:13102948XXX@sip-in.les.net.
DialPlan 12:14:55:494 sip1(3840): SDP on UAC response had public IP not mangled, RTP socket 72.51.34.70:14298.
DialPlan 12:14:55:494 sip1(3840): Cancelling all call legs for ForkCall app.
DialPlan 12:14:55:494 sip1(3840): Answering client call with a response status of 200.
DialPlan 12:14:55:494 sip1(3840): Cancelling all call legs for ForkCall app.
DialPlan 12:14:55:494 sip1(3840): Answering client call with a response status of 200.
DialPlan 12:14:55:494 sip1(3840): Dial command was successfully answered in 1.50s.
DialPlan 12:14:55:494 sip1(3840): Dialplan cleanup for 902771.
DialPlan 12:14:55:494 sip1(3840): Dial command was successfully answered in 1.56s.
DialPlan 12:14:55:494 sip1(3840): Dialplan cleanup for 902771.
DialPlan 12:14:55:541 sip1(3840): Dial plan execution completed with normal clearing.
DialPlan 12:14:55:541 sip1(3840): Dial plan execution completed with normal clearing.
NATKeepAlive 12:14:56:635 sip1(10252): Requesting NAT keep-alive from proxy socket udp:67.222.131.147:5060 to udp:72.67.24.28:18419.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Force CID stopped working with new server

Post by Aaron » Sun Jul 01, 2012 12:18 am

The problem has come about due to a change that was made to the way calls traverse dialplans that was introduced a week or two before the server migration.

Previously a call to a sipsorcery SIP account from within a dialplan was always forwarded directly to that account's registered bindings and any incoming dialplan setting was ignored. In May a user contacted me with a scenario where they needed to be able to have calls to a sipsorcery SIP account processed by a dialplan so after reviewing the implications I enabled that behaviour. Unfortunately that change has impacted your calls although it should be easily remedied.

What's happening is:

1. An incoming call arrives on 444401 and gets processed by your callSXM dialplan,

2. In the callSXM dialplan your forward the call to 902779@sipsorcery.com and since your 902779 SIP account has an incoming dialplan set the call ends up in your "902XXX Plan". Previously it would have been forwarded to the SIP account bindings for your 902779 SIP account and NOT have been processed by the dialplan,

3. in your "902XXX Plan" you forward the call to 13102948XXX@sip-in.les.net[fd=33445566] which then gets processed normally.

To avoid the use of the executing the "902XXX Plan" in step 2 you could remove the incoming dialplan setting on your 902779 SIP account. You should only set an incoming dialplan setting on a SIP account if you do actually want calls to that account processed by a dialplan rather than forwarding them to the account's registered bindings. In most cases you don't need an incoming dialplan set.

ronf
Posts: 6
Joined: Mon Jun 18, 2012 5:24 pm

Re: Force CID stopped working with new server

Post by ronf » Mon Jul 02, 2012 8:03 pm

Thanks Aaron, when SIP accounts and Dial Plans are not crossed the calls do route correctly. This part nicely solved!

However something else also has changed. Until a few weeks ago, each unique incoming IPKall DID could have its callers CID forced in SipSorcery and then be Fwded to one general DID. The general DID then routed the call to FreePBX, which could route each specific CID to each appropriate Exten. (This avoids 1-way audio issues and enables a specific group of callers to reach the same specific Exten). Since a few weeks ago, when a SipSorcery (forced CID) incoming call arrives into FreePBX, it is dumped into the "Any DID / Any CID" route even though the CID appears to have been changed.

FreePBX LOG:
Line 1: CID is forced within Les.net. FreePBX routes to correct Exten, but CID is changed globally (per DID) for ALL incoming callers. This works fine but requires multiple Les.net DIDs for each infrequent different user or group).

Line 2: CID is forced within SipSorcery, then sent to a single Les.net DID per group of callers. Les.net call goes to FreePBX but does not route to Exten in FreePBX. This CID incoming routing used to work fine a few weeks ago.


Calldate Channel Source Clid Dst Disposition Duration

1. 2012-07-01 14:04:10 SIP/115521... 3787523 "PENDING" <3787523> EXT ANSWERED 00:08
2. 2012-07-01 13:52:26 SIP/115521... 3787523 "3787523" <3787523> s ANSWERED 00:05

The clue probably has something to do with the "PENDING" vs "3787523" data, but I get lost here. Thanks again for any help.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Force CID stopped working with new server

Post by Aaron » Tue Jul 03, 2012 9:40 am

Is the FreePBX treating sipsorcery as a trunk? If so it's probably tied the trunk to an IP address and since the sipsorcery IP address has just changed the configuration at the FreePBX end may need to be updated. Anywhere you see 69.59.142.213 it needs to be updated to 67.222.131.147.

ronf
Posts: 6
Joined: Mon Jun 18, 2012 5:24 pm

Re: Force CID stopped working with new server

Post by ronf » Tue Jul 03, 2012 11:08 am

I don't see 69.59.142.213 anywhere but don't know where else it may also show up. All of the 6 trunks in FreePBX show as 67.222.131.147 in "Asterisk info, Sip Peers".

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Force CID stopped working with new server

Post by Aaron » Wed Jul 04, 2012 3:38 am

In don't think the problem is related to the "PENDING" line. That is most likely indicating that the call is in a pending state awaiting an answer. But apart from that I'm at a bit of a loss really. Maybe if you could simplify the call flow to try and narrow down the problem it would help. For example if you can take one of the providers out of the call path and see if it works as expected and then do the same for the other one it will provide a further hint.

Post Reply