News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Strange Behavior using USB PTSN on Obi202

Started by Hortoristic, February 24, 2014, 01:20:14 PM

Previous topic - Next topic

Hortoristic

I bought the USB PTSN Line adapter for my Obi202.  

I'm able to make and receive calls ok.  However; my call history looks strange when receiving calls.

I have only 2 - SP's enabled.  SP2 is my Voip.Ms for international dialing and SP4 is an international DID, and then there is my PTSN line, that is hooked up to Comcast.

I still have everyone dial my Google Voice number - which I forward to my Comcast number.  Although making and receiving calls is working; here is what I see when I receive a call:

First off here is my Phone1 port OutboundCallRoute (unsure if this has impact):
{911:li},{([1-9]x?*(Mpli)):pp},
{(<#:>):ph2}, what is this one doing - is this forwarding all calls to SP2 maybe?
{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}

Whenever 1 call comes in, my call history shows two calls; why does call 2 look like it's handed off to Call 1 - why is SP2 even in the mix at all?:
Call 1:
12:56:20  From LI1()        To PH1
12:56:27  Call Ended

Call 2:
12:56:11  From SP2()       To PH1
12:56:11                        Ringing
12:56:20                        Call Connected
12:57:25                        Call Ended

azrobert

<:> in a rule is comparing for the string left of the colon. If you get a match that string is removed from the dialed number. Anything to the right of the colon is added to the dialed number. Then the call is routed to the trunk specified. I hope this clear.

{<#:>:ph2}

You are comparing for #. If there is a match the # is dropped and the call is routed to ph2.
In plain English when you dial # from Phone Port 1 you are calling Phone Port 2.


Is the call coming in on Li or SP2?
Please post the InboundCallRoutes for Li and SP2.

Hortoristic

#2
I got some strange strings fo SP2 - I think this is where I was re-routing some calls based on Caller ID to allow friends in UK to dial a DID there that then re-dialed a cell phone here in USA via Google Voice on SP1.  Another setting was when a particular local DID here in USA was called, it would re-dial an out of country number; basically allowing us to call out of country by calling a local number - I could reset this to default if we think it's breaking something:

X_InboundCallRoute:
{(16046985518):aa}, -- any call from 16046985518 should get AA
{(13604703652)>(19142961123):sp2(011441903208888)}, -- if 19142961123 was called from 13604703652, then dial out SP2: 011441903208888
{(13604708123)>(19142961111):sp1(13604703562)}, -- if 19142961111 was called from 13604708123, then dial out SP1: 13604703562
{>44113604708123:sp1(13605158499)}, -- if any number calls this UK DID, then dial local cell number: 13605158499 from SP1
{(x|xx|xxx|xxxx|xxxx|xxxxxx|un@@.):}, -- a great SIP scanner avoidance string
{ph}

InboundCallRoute for LINE Port:
ph

Since I call my GV number, which forwards to my Comcast number, which the wire goes to the USB PTSN line adapter - it should be reflective of coming in on LI1.

azrobert

I don't see anything in the inbound routes that would cause this behavior. I'm out of ideas.

Hortoristic

#4
I just checked my free Callcentric account, and it's appearing GV is still forwarding my numbers to CC; which would make sense since CC is setup to come in on SP2.

Very weird - I triple checked that I un-forwarded my GV from CC to Comcast.  

Problem solved!  Although I had unchecked forwarding to my CC account and had only checked my Comcast number, when I deleted the CC # from the Google Voice interface, it's all working as it should - it's like GV was really deselecting my forward for me although box was unchecked.  Sorry for wasting your time!