OBi200 and 202 Power Adapter
Taoman:
Quote from: SteveInWA on March 05, 2015, 09:07:59 pm
Quote from: Taoman on March 05, 2015, 08:47:58 pm
Quote from: SteveInWA on March 05, 2015, 08:24:23 pm
With Callcentric, for example, I have a call treatment that rings my desired extensions, plus 1<nomorobo's number>@tf.callwithus.com
Although I haven't actually tried it I think you can do something similar by simply forking your X_InboundCallRoute with something like:
ph,sp2(18661234567@tf.callwithus.com;ui=$1)
Talk about derailing a discussion with an untested solution. I'm sticking with implementing it the way the service is designed to be used -- with the telco's simultaneous ring service.
That's rich. You devote 3 paragraphs to the subject yet I'm the one "derailing a discussion." Talk about the pot calling the kettle black. Sometimes your arrogance is astounding.
This is not an "untested solution." I said I haven't actually tried it. There are multiple threads on this site showing the specifics and that it does indeed work. I don't just post random ideas that float through my head.
202Owner:
Quote from: azrobert on March 06, 2015, 07:08:12 am
Quote from: 202Owner on March 06, 2015, 05:51:28 am
And, I don't understand the need to specify the userID = the mapped CallerID number, $1. Calling tf.callwithus.com requires no account and no user authentication credentials.
You are supplying the callerid to CallWithUs then CWU will pass it to NoMoRobo. If you don't do this, all calls will be rejected by NoMoRobo.
Makes sense. I'm just not following the syntax. From my notes:
*****
Format: TK(uri;ui=userid[:password];op=[ i ][ m ][ n ][ s ])
Option flags: i=ice, m=symmetric-rtp, n=use-natted-address, s=stun
Examples:
Speed Dial = sp1(xxx-xxx-xxxxx@sip.inum.net;ui=1000:xyz;op=sm)
Voice Gateway AccessNumber = sp1(sip.inum.net;ui=1000;op=imns)
Notes:
1. ui=userid[:password] overwrites any Voice Gateway AuthUserID and AuthPassword setting.
2. If SPn stun is disabled, then the stun client is disabled and attempting s=stun may crash.
And for inbound call routes:
terminal-list = terminal,terminal,…. (comma-separated list of 0 or more terminal objects)
terminal = PHn OR AAn OR LIn(arg) OR SPn(arg) OR PPn(arg) n=1,2,3,4 where applicable
arg = cid>target
cid = spoofed-caller-number OR $1
target = number-to-call OR $2
An empty arg object implies the arg with the target $2 and no cid. The () can be omitted.
An empty cid object implies no CallerID spoofing when making the call on the specified trunk. The > can be omitted.
An empty target object implies the target $2, which means to call the original called number after applying any necessary digit map transformation implied by the rule. The > cannot be omitted if the cid is not empty.
Spoofed-caller-number and number-to-call are literal strings.
$1 is an internal variable containing the value of the caller number of this inbound call, after any digit map transformation in the matched caller object of the matched peering object in the peering-list.
$2 is an internal variable containing the called number of this inbound call, after any digit map transformation in the matched callee object of the matched peering object in the peering-list.
***
So given the suggested fork to sp2(18661234567@tf.callwithus.com;ui=$1), I don't follow setting the userid, ui, equal to the inbound cid, $1. I understand wanting to route/fork the inbound CID to Nomorobo, but I don't understand using the userid paramenter to do this.
I also ask, shouldn't the inbound CID follow the fork route without assistance? Maybe the OBi breaks this. I should go find and read the other thread mentioned.
SteveInWA:
Quote from: Taoman on March 06, 2015, 10:57:42 am
Quote from: SteveInWA on March 05, 2015, 09:07:59 pm
Quote from: Taoman on March 05, 2015, 08:47:58 pm
Quote from: SteveInWA on March 05, 2015, 08:24:23 pm
With Callcentric, for example, I have a call treatment that rings my desired extensions, plus 1<nomorobo's number>@tf.callwithus.com
Although I haven't actually tried it I think you can do something similar by simply forking your X_InboundCallRoute with something like:
ph,sp2(18661234567@tf.callwithus.com;ui=$1)
Talk about derailing a discussion with an untested solution. I'm sticking with implementing it the way the service is designed to be used -- with the telco's simultaneous ring service.
That's rich. You devote 3 paragraphs to the subject yet I'm the one "derailing a discussion." Talk about the pot calling the kettle black. Sometimes your arrogance is astounding.
This is not an "untested solution." I said I haven't actually tried it. There are multiple threads on this site showing the specifics and that it does indeed work. I don't just post random ideas that float through my head.
BigJim brought up Nomorobo, MurryB asked how to do it, and I answered him, with a method that is closest to the way that Nomorobo was designed to operate: using a telephone company's simultaneous ringing feature. My philosophy is to always select solutions that the majority of users (not just techies) can understand and implement, with the least complexity, that are reliable, robust, and least-likely to be inadvertently broken by some other configuration change. In the case of OBi issues, the majority of entry-level users can configure the service to meet their needs by using the portal in non-expert mode. In this specific example, having the ITSP handle call-forking (simultaneous ringing) makes more sense, as it happens at the carrier level, avoiding the round trip to the OBi and then out to the TFN. Given that lots of folks make changes to their OBi call routing, and would have to remember why they set up that route, when some future tweak breaks things, it's just better system design to keep the action at the ITSP.
In my own use case, I configured Callcentric to simultaneously ring not only my OBi devices, but two other non-OBi destinations and to nomorobo. In this configuration, forking to nomorobo at the OBi wouldn't be the ideal solution.
Now, if you think that is astounding arrogance, then I would question why you continue to direct your hostility at me, instead of simply following the way of Tao, to find balance and peace in life -- it's not worth the negative energy, and I certainly can do without it.
202Owner:
Quote from: 202Owner on March 06, 2015, 04:15:15 pm
So given the suggested fork to sp2(18661234567@tf.callwithus.com;ui=$1), I don't follow setting the userid, ui, equal to the inbound cid, $1. I understand wanting to route/fork the inbound CID to Nomorobo, but I don't understand using the userid paramenter to do this.
I also ask, shouldn't the inbound CID follow the fork route without assistance? Maybe the OBi breaks this. I should go find and read the other thread mentioned.
To follow-up, the SIP URI format SPn(800-xxx-xxxx@tf.callwithus.com;ui=$1) is valid. CallWithUs free toll-free requires a valid US CallerID and accepts/delivers userID=ui=xxx-xxx-xxxx (omit dashes) as the CallerID number (verified by calling ANI Verification by MCI: 1-800-437-7950). Using internal variable $1 to pass the inbound CallerID should work when simulringing/forking the inbound call route to Nomorobo. I'd test it but I don't want to use Nomorobo.
Thanks for the tip, Taoman! I've updated my CallWithUs free toll-free voice gateway to pass my CallerID as noted in my notes http://ozarkedge.mypressonline.com/index.htm.
Navigation
[0] Message Index
[*] Previous page