Inplan question

Catalog of dial plans
Post Reply
uhf
Posts: 26
Joined: Sat Oct 30, 2010 3:05 am

Inplan question

Post by uhf » Tue Nov 09, 2010 6:04 pm

I want to make a dial plan that can ring my main account, and a subaccount (or two). But, if the main main account is not available in, then forward the call to my cellphone instead.
Here's what I have so far, which I haven't had time to even test, since I never seem to be physically where that main account's ATA is when I have time to think about this problem.

Code: Select all

if sys.IsAvailable() then
     sys.Dial("#{sys.myaccount}@local",20)
     sys.Respond(480, "#{sys.myaccount} Not available")
  else
     sys.Dial("1npxnxxxxxx@Callcentric",30)
     sys.Respond(480, "#{sys.myaccount} Not available")
  end
Does that first line determine if the main sip account is logged in, or if any of my sip accounts are logged in?
And if I add subaccounts, and they aren't available, how will that affect things? The other accounts will likely only be used intermittently.

I'm a total noob to this stuff.

MikeTelis
Posts: 1582
Joined: Wed Jul 30, 2008 6:48 am

Re: Inplan question

Post by MikeTelis » Tue Nov 09, 2010 7:03 pm

May I suggest the following solution:

sys.Dial("#{sys.Username}@local&sub1@local&sub2@local&1npxnxxxxxx@Callcentric[dt=20]")

It will ring your main SIP account, sub1 and sub2 SIP accounts simultaneously. If there is no answer within 20 sec, the call will be forwarded to your cell. If there is no bindings (no SIP registrations to any of your SIP accounts), your cell phone will start ringing immediately.

sys.IsAvailable() check the bindings (registrations) onto your main SIP account. Note that on rare occasions it might return true even though your ATA/softphone is having problems with registration ("orphan registration"), that's why I prefer the above solution.

uhf
Posts: 26
Joined: Sat Oct 30, 2010 3:05 am

Re: Inplan question

Post by uhf » Tue Nov 09, 2010 7:34 pm

Hmm.. I don't normally want any calls to go to my cell unless my ATA is down. The preferred place for unanswered calls would be for Callcentrics voicemail to pick them up when I don't answer. However, in the event that I have a power or internet failure at home, then I want all calls going to my cell.

MikeTelis
Posts: 1582
Joined: Wed Jul 30, 2008 6:48 am

Re: Inplan question

Post by MikeTelis » Tue Nov 09, 2010 8:11 pm

Then go with your original script. Use IsAvailable('sub1','sipsorcery.com') to check if something's registered to sub1 account:

Code: Select all

if sys.IsAvailable() || IsAvailable('sub1','sipsorcery.com') || IsAvailable('sub2','sipsorcery.com') then
     sys.Dial("#{sys.Username}@local&sub1@local&sub2@local",20)
     sys.Respond(480, "#{sys.Username} Not available")
  else
     sys.Dial("1npxnxxxxxx@Callcentric",30)
     sys.Respond(480, "#{sys.Username} Not available")
  end

uhf
Posts: 26
Joined: Sat Oct 30, 2010 3:05 am

Re: Inplan question

Post by uhf » Tue Nov 09, 2010 9:52 pm

Thanks for your help, Mike, I'll give this a try later on when I'm home and see how it works for me.

gbhasu
Posts: 2
Joined: Thu Nov 11, 2010 12:50 am

Re: Inplan question

Post by gbhasu » Thu Nov 11, 2010 1:17 am

Hi Mike,
Thanks at the outset for extending your help to everyone on this forum.
I solicit your help in understanding the problem I have in getting calls forwarded to sipsorcery.
I have a gizmo account and I added that to my sipsorcery account. But I dont get the incoming call forwarded to my sipsorcery account. I attach the call trace here. Could you please point where I have gone wrong?
---------------------------------------------------------------
DialPlan 00:56:17:319 sip1(5452): Using dialplan Multisip for In call to sip:gbhasu@sipsorcery.com;rinstance=726886.
NewCall 00:56:17:319 sip1(5452): Executing script dial plan for call to gbhasu.
DialPlan 00:56:17:459 sip1(5452): ** Call from <sip:+907000342900@10.142.66.5>;tag=2118610916 to gbhasu **
DialPlan 00:56:17:459 sip1(5452): Local time: 11/10/2010 19:56
DialPlan 00:56:17:475 sip1(5452): Caller's number: '907000342900'
DialPlan 00:56:17:491 sip1(5452): URI dialing: gbhasu@local[fu=907000342900]
DialPlan 00:56:17:491 sip1(5452): Commencing Dial with: gbhasu@local[fu=907000342900].
DialPlan 00:56:17:506 sip1(5452): Call leg is for local domain looking up bindings for gbhasu@sipsorcery.com for call leg gbhasu@local.
DialPlan 00:56:17:522 sip1(5452): 5 found for gbhasu@sipsorcery.com.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:51352;transport=udp.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:59324;transport=udp.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:5060.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:56853;transport=udp.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:49416;transport=udp.
DialPlan 00:56:17:522 sip1(5452): SIPClientUserAgent Call using alternate outbound proxy of udp:69.59.142.213:5060.
DialPlan 00:56:17:522 sip1(5452): SIPClientUserAgent Call using alternate outbound proxy of udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): SIPClientUserAgent Call using alternate outbound proxy of udp:69.59.142.213:5060.
DialPlan 00:56:17:522 sip1(5452): SIPClientUserAgent Call using alternate outbound proxy of udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): Switching to sip:gbhasu@98.216.252.64:56853 via udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): SIPClientUserAgent Call using alternate outbound proxy of udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): Switching to sip:gbhasu@98.216.252.64:49416 via udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): SDP on UAC call had public IP not mangled, RTP socket 74.125.154.80:24600.
DialPlan 00:56:17:538 sip1(5452): SDP on UAC call had public IP not mangled, RTP socket 74.125.154.80:24600.
DialPlan 00:56:17:538 sip1(5452): Switching to sip:gbhasu@98.216.252.64:5060 via udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): SDP on UAC call had public IP not mangled, RTP socket 74.125.154.80:24600.
DialPlan 00:56:17:538 sip1(5452): Switching to sip:gbhasu@98.216.252.64:59324 via udp:69.59.142.213:5060.
DialPlan 00:56:17:522 sip1(5452): Switching to sip:gbhasu@98.216.252.64:51352 via udp:69.59.142.213:5060.
DialPlan 00:56:17:538 sip1(5452): SDP on UAC call had public IP not mangled, RTP socket 74.125.154.80:24600.
DialPlan 00:56:17:538 sip1(5452): SDP on UAC call had public IP not mangled, RTP socket 74.125.154.80:24600.
NATKeepAlive 00:56:18:022 sip1(2548): Requesting NAT keep-alive from proxy socket udp:69.59.142.213:5060 to udp:98.216.252.64:49416.
NATKeepAlive 00:56:18:022 sip1(2548): Requesting NAT keep-alive from proxy socket udp:69.59.142.213:5060 to udp:98.216.252.64:56853.
NATKeepAlive 00:56:23:084 sip1(2548): Requesting NAT keep-alive from proxy socket udp:69.59.142.213:5060 to udp:98.216.252.64:5060.
DialPlan 00:56:23:147 sip1(5452): Client call cancelled halting dial plan.
DialPlan 00:56:23:147 sip1(5452): Dialplan call was terminated by client side due to ClientCancelled.
DialPlan 00:56:23:147 sip1(5452): Cancelling all call legs for ForkCall app.
DialPlan 00:56:23:147 sip1(5452): Cancelling forwarded call leg, sending CANCEL to sip:gbhasu@98.216.252.64:51352;transport=udp.
DialPlan 00:56:23:147 sip1(5452): Cancelling forwarded call leg, sending CANCEL to sip:gbhasu@98.216.252.64:59324;transport=udp.
NATKeepAlive 00:56:23:147 sip1(2548): Requesting NAT keep-alive from proxy socket udp:69.59.142.213:5060 to udp:98.216.252.64:59324.
DialPlan 00:56:23:147 sip1(5452): Cancelling forwarded call leg, sending CANCEL to sip:gbhasu@98.216.252.64:5060.
DialPlan 00:56:23:162 sip1(5452): Cancelling forwarded call leg, sending CANCEL to sip:gbhasu@98.216.252.64:56853;transport=udp.
DialPlan 00:56:23:162 sip1(5452): Cancelling forwarded call leg, sending CANCEL to sip:gbhasu@98.216.252.64:49416;transport=udp.
DialPlan 00:56:23:162 sip1(5452): Dial command was halted by cancellation of client call after 5.64s.
DialPlan 00:56:23:162 sip1(5452): Dialplan cleanup for gbhasu.
DialPlan 00:56:23:491 sip1(5452): Dial plan execution completed with normal clearing.
----------------------------------------------------------------------------------------------------------------------------------------------------

Thanks in advance,
Bhaskar

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

Re: Inplan question

Post by Aaron » Thu Nov 11, 2010 1:30 am

The call was forwarded to your SIP account bindings and then cancelled by the caller after 5.64 seconds.

I suspect your issue is related to the number of bindings you have ended up with:

DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:51352;transport=udp.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:59324;transport=udp.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:5060.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:56853;transport=udp.
DialPlan 00:56:17:522 sip1(5452): ForkCall commencing call leg to sip:gbhasu@98.216.252.64:49416;transport=udp.

If you only have one device (ATA or phone) registering with sipsorcery then it looks like your router/ATA is playing fun and games as you've ended up with 5 bindings for the same device. You could try setting up a port forward for UDP port 5060 on your router to go to your ATA. Hopefully that will mean the router only ever sends your SIP traffic from a single port.

gbhasu
Posts: 2
Joined: Thu Nov 11, 2010 12:50 am

Re: Inplan question

Post by gbhasu » Thu Nov 11, 2010 2:05 pm

Hi Aaron,
Thank you very much for looking at the trace. In fact, there are multiple bindings. I did not know that that would make it difficult for the incoming call to be forwarded to any device. I would remove all bindings except one and try if that solves the problem.

Bhaskar

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

Re: Inplan question

Post by Aaron » Thu Nov 11, 2010 10:03 pm

Mulitple bindings are not an issue for sipsorcery but they'll often confuse the average NAT/router if a call comes in for all of them at once.

Post Reply