News:

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

Main Menu

LINE Port=>InboundCallRoute max length

Started by karog, November 15, 2014, 04:06:28 PM

Previous topic - Next topic

karog

Obi110 1.3.0 Build 2872

I have successfully used the InboundCallRoute to block calls. Before I upgraded to Build 2872 the max length of that field in my browser was 512 thus limiting the list of numbers I could block there. This was before I learned about possibly using the DigitMap for this.

But with Build 2872 I now find the max length of the fields both for InboundCallRoute and DigitMaps appears to be 65535. I would expect that if I tried to save a very long string, one longer than could be saved, that it would be rejected. But call me paranoid, I would hate to try and have it overwrite something and somehow brick my device.

Can anyone verify how long a string can be saved into InboundCallRoute and DigitMaps?

azrobert

I don't know the answer to your question.

I use NoMoRobo to block robo calls.
You can use your method for calls that NoMoRobo missses.

See:
http://www.obitalk.com/forum/index.php?topic=8802.msg58434#msg58434


PeSiw

#2
I am curious as well ... any more information on the maximum length of fields?



karog

#5
Getting no response, I decided to experiment. The answer is complicated.

First, it appears that trying to submit a too long value will simply fail and not alter the device. You don't get an error of any kind but you also don't get the "successful" message and the request to reboot.

I did a binary search on length for InboundCallRoute trying various lengths. Too long failed and short enough succeeded after which I also verified the saved value. In my case the max length was 1433. I didn't know then if that was all extra available memory of just that field. I tried similar in User Defined Digit Maps field. They too came in around 1433 or so.

I then tried to put long values in several Digit Maps fields and this failed at first. But then I discovered I could put in several long values as long as I submitted (but not rebooted) after each one individually. I have tested up to four long values in Digit Maps fields and now have a vague recollection that a fifth failed.

My purpose was to create a long block list. I now define 4 Digit Maps fields as ignore0, ignore1, ignore2, and ignore3. I reference all of these in the InboundCallRoute. I have chosen to store at most 100 10 digit numbers plus |'s and enclosing () for a total of 1101 chars per map. This allows me to block up to 400 numbers. I could probably increase the number per map to 125 giving me 500 blocked numbers. Of course I could look for patterns and capture redundancy but I find no real need.

Right now I have about 120 blocked numbers so I have plenty of head room and use only ignore0 and ignore1. In ignore2 and ignore3 I use a default value of (0000000000) until my list grows that long.

It seems to work pretty well and the block list can be shared among trunks so I reference it in the InboundCallRoute of both the Line port and SP1.

giqcass

A user defined macro could replace
"ignore0, ignore1, ignore2, and ignore3" in the InboundCallRoute.

What you have done has got me wondering if the process of adding blocked number could be refined.
Long live our new ObiLords!

karog

Quote from: giqcass on December 17, 2014, 07:29:37 AM
A user defined macro could replace
"ignore0, ignore1, ignore2, and ignore3" in the InboundCallRoute.

What you have done has got me wondering if the process of adding blocked number could be refined.

I am not familiar with user defined macros in this context. Would you elaborate? Give an example?

giqcass

#8
A user defined macro is like a variable.  It can be used to pull data from a system variable or it can contain static data.  It's useful if you want to use the same value in many places.  I haven't used one in the InboundCallRoute however it should work if you set "ExpandIn = ALL".  It would only be worth the added fuss if you mess with the InboundCallRoute a lot.  

System Management
>>>>>>>>>>>>>>>Auto Provisioning
>>>>>>>>>>>>>>>>>>>>>>>>>>Set User Defined Macro 0 as follows.

Value = whatever you want
ExpandIn = ALL

Now $UDM0 = whatever you want


EDIT: I'm trying to work out if it is possible to add numbers to the blocked list from the phone keypad.
Long live our new ObiLords!

karog

#9
Quote from: giqcass on December 17, 2014, 09:18:51 AM
A user defined macro is like a variable.  It can be used to pull data from a system variable or it can contain static data.  It's useful if you want to use the same value in many places.  I haven't used one in the InboundCallRoute however it should work if you set "ExpandIn = ALL".  It would only be worth the added fuss if you mess with the InboundCallRoute a lot.  

System Management>>>Auto Provisioning>>>Set User Defined Macro 0 as follows.

Value = whatever you want
ExpandIn = ALL

Now $UDM0 = whatever you want

EDIT: I'm trying to work out if it is possible to add numbers to the blocked list from the phone keypad.

Thanks for the response.

I keep a txt file with the numbers I block, one per line. And I allow comments so I can include numbers I don't want to block but want to notate because they contain poor callerID info so that I don't accidentally block them in the future eg amazon help callback, google voice verification callback, etc.

I actually keep two copies of the file. One is what is currently stored on the OBi and one is a copy that I edit. Then I run a bash script I wrote that compares the two files and constructs the changed Digit Maps and writes out the the modified ones with their names so that I can easily copy and paste them in.

That is certainly more work than pushing a quick phone keypad combo but works for me. If you come up with something along that line, I would appreciate hearing about it.

EDIT: Now that I think about it, rather than using a User Defined Macro to consolidate the ignore references, I could just use another Digit Map for that. But I don't change that part of the InboundCallRoutes anyway so it is not really worth it. The main changes I make to the InboundCallRoutes is what to do with calls that pass the block filter. Right now I send them to both PH and out SP1 (a GV number) to a different GV number that rings in Hangouts on my Moto X. I might change that to send the Moto X just specific numbers rather than all non-blocked calls. I haven't decided that yet.

giqcass

You may find this thread useful/funny.
https://www.obitalk.com/forum/index.php?topic=7413.15

We were discussing alternatives to blocking calls.  Like forwarding the call to the number that called us.  Things that might annoy the telemarketers or cause them to remove us from their list.
Long live our new ObiLords!

karog

#11
Quote from: giqcass on December 17, 2014, 10:15:22 AM
You may find this thread useful/funny.
https://www.obitalk.com/forum/index.php?topic=7413.15

We were discussing alternatives to blocking calls.  Like forwarding the call to the number that called us.  Things that might annoy the telemarketers or cause them to remove us from their list.

Pretty funny. I snagged a copy of your pleasehold.wav file and hope I can find a proper place to use it.

On the calls I am forwarding to my cell, I added $1> to the SP1 arg but it hasn't been working. In the thread you cited, it mentions X_SpoofCallerID which I was unaware of so I set that but that appears not be enough. Lower in the thread someone stated that $1 for caller number doesn't work so that may be why or maybe GV won't allow the spoofing. I just want the actual incoming callerID info to be forwared to my cell rather than the SP1 number through which I am doing the forwarding. It would seem to me that forwarding should defaultly carry the incoming callerID info with the option to change that.

giqcass

Google voice does not support caller ID spoofing. When the Obi forwards a call it is not technically forwarding. In reality it is making a second call and then bridging the two.  That is why CID spoofing is needed.  Some providers do allow this type of spoofing.   
Long live our new ObiLords!

azrobert

Quote from: karog on December 17, 2014, 10:52:03 AM
On the calls I am forwarding to my cell, I added $1> to the SP1 arg but it hasn't been working.

If you install an SIP softphone on your cell and register it to a service like SIP2SIP then you can pass callerid. Use {ph,sp2(Your_SIP2SIP_userid@sip2sip.info;ui=$1)} in your inbound call route. SP2 must be defined as SIP. Callcentric also has free accounts.

giqcass

#14
Quote from: azrobert on December 17, 2014, 02:13:25 PM
If you install an SIP softphone on your cell and register it to a service like SIP2SIP then you can pass callerid. Use {ph,sp2(Your_SIP2SIP_userid@sip2sip.info;ui=$1)} in your inbound call route. SP2 must be defined as SIP. Callcentric also has free accounts.
Not everyone's favorite but for me the Obion app seems to work alright as well.

I also like Csipsimple.
Long live our new ObiLords!

karog

Quote from: azrobert on December 17, 2014, 02:13:25 PM
If you install an SIP softphone on your cell and register it to a service like SIP2SIP then you can pass callerid. Use {ph,sp2(Your_SIP2SIP_userid@sip2sip.info;ui=$1)} in your inbound call route. SP2 must be defined as SIP. Callcentric also has free accounts.
I have been giving this a try today. I have no experience with sip.

I created an account with sip2sip.info and installed Zoiper soft phone on my cell and registered it. I see it in the SIP Devices list on my sip2sip.info account and in Zoiper it lists the account as ready so that much looks good. I have no other way to test it this evening other than with the rest of what I am attempting. Sunday or Monday I can ask a friend who has some SIP accounts to help.

As for OBi configuration, I changed the InboundCallRoute for the LINE port as you suggested with my user id.

I had a second GV number in SP2 and removed that. And later did the whole device removal from OBiTalk to start clean.

Then I tried to setup ITSP B and SP2. This may be where I went wrong as calls are not ringing on my cell.

ITSP B General I set SignalingProtocol to SIP and gave it a name. The rest is default.

ITSP B SIP I set ProxyServer to proxy.sipthor.net, checked X_SpoofCallerID, the rest default.

ITSP RTP all default.

SP2 Enabled, B profiles, AuthUserName, and AuthPassword (same as for Zoiper), the rest default.

When I call my LINE number from my tablet with Hangouts and a GV#, my home phone rings but the cell does not.

I suppose it could be a router setting (tomatousb on asus rt-n16). I unchecked SIP in NAT Helpers as that is supposed to be tomatousb's name for SIP ALG. The OBi110 has no problems with the router.

Should both my OBi110 and Zoiper be logged into the same sip2sip.info account? Note that I do not see the OBi110 listed in the SIP Devices list on the sip2sip.info account.

Any suggestions?

I also installed OBion and changed the forwarding in LINE. That seemed to work perhaps tolerably. I would like to get the SIP solution to work for comparison. OBion hasn't been supported in several years.

Thanks for all the input. And sorry I have been absent a few days but other priorities asserted themselves.

giqcass

#16
It looks like you set up both the sip software and the Obi to use the same account.  I think that might be part of your problem.  It should be 2 different accounts.  Did you set the lines inbound call route to {ph,sp2(Your_SIP2SIP_userid@sip2sip.info;ui=$1)} like azrobert  suggested?

Your_SIP2SIP_userid@sip2sip .info should be the account registered on you cell phone.
Long live our new ObiLords!

azrobert

You don't need to register SP2 to SIP2SIP.
You are sending the call directly to SIP2SIP with an SIP URI.
This is an SIP URI:
Your_SIP2SIP_userid@sip2sip.info;ui=$1

When you route a call like this, SP2 must be defined as a valid SIP Trunk to any provider.

I'm not sure why your setup doesn't work, but you can setup a dummy trunk like this:
Service Providers -> ITSP Profile B -> SIP -> ProxyServer: 127.0.0.1
Voice Services -> SP2 Service -> AuthUserName: (any userid)
Voice Services -> SP2 Service -> X_RegisterEnable: (unchecked)
Voice Services -> SP2 Service -> X_ServProvProfile: B

You don't need to enable X_SpoofCallerID.
The ui=$1 will pass the CallerID

If you enable X_SpoofCallerID then use this in the X_InboundCallRoute:
{ph,sp2(Your_SIP2SIP_userid@sip2sip.info)}

When you use X_SpoofCallerID the CallerName is also passed, but since GV doesn't supply cname it doesn't matter.


karog

Quote from: giqcass on December 20, 2014, 07:20:53 PM
It looks like you set up both the sip software and the Obi to use the same account.  I think that might be part of your problem.  It should be 2 different accounts.  Did you set the lines inbound call route to {ph,sp2(Your_SIP2SIP_userid@sip2sip.info;ui=$1)} like azrobert  suggested?

Your_SIP2SIP_userid@sip2sip .info should be the account registered on you cell phone.

I was composing a response to you when azrobert replied. So I will go try his suggestion. But yes I used the correct InboundCallRoute as he had previously guided. See my 3rd paragraph in my previous response.

I wondered how to setup the sip trunk on the OBi and took a shot. I was hoping I didn't need a 2nd account. Being able to use a dummy one sounds promising.

karog

Quote from: azrobert on December 20, 2014, 07:32:09 PM
You don't need to register SP2 to SIP2SIP.
You are sending the call directly to SIP2SIP with an SIP URI.
This is an SIP URI:
Your_SIP2SIP_userid@sip2sip.info;ui=$1

When you route a call like this, SP2 must be defined as a valid SIP Trunk to any provider.

Yes, I thought I needed a SIP trunk on SP2 but didn't know any other option than to try and use the same account.

Quote from: azrobert on December 20, 2014, 07:32:09 PM
I'm not sure why your setup doesn't work, but you can setup a dummy trunk like this:
Service Providers -> ITSP Profile B -> SIP -> ProxyServer: 127.0.0.1
Voice Services -> SP2 Service -> AuthUserName: (any userid)
Voice Services -> SP2 Service -> X_RegisterEnable: (unchecked)
Voice Services -> SP2 Service -> X_ServProvProfile: B

You don't need to enable X_SpoofCallerID.
The ui=$1 will pass the CallerID

If you enable X_SpoofCallerID then use this in the X_InboundCallRoute:
{ph,sp2(Your_SIP2SIP_userid@sip2sip.info)}

When you use X_SpoofCallerID the CallerName is also passed, but since GV doesn't supply cname it doesn't matter.

I tried this without SpoofCallerID and with the ui=$1; and no ring on the cell.

And since the incoming call to the OBi is on my LINE port - Xfinity Voice - there is name and number callerID so I would like both forwarded to the cell soft phone. In this method, there is no GV as part. I can worry about which form to use to pass calleriD info AFTER I manage to get the call through to the cell.

Thanks for the ideas. Maybe tomorrow I will get a 2nd SIP2SIP account to use as the SP2 SIP trunk.