I just realized that if someone leaves a message at our PSTN (LINE port) the visual and audible notifications are not forwarded to the PHONE port.
Is there ANY way to know if there is a message waiting, besides pressing #?
Thanks
The OBi doesn't support MWI through the LINE Port.
Thanks for the info.
That's the first big "BUMMER" i bump into, with this unit.
Can it detect the "stutter" tone and notify it somewhere in its web interface?
I tried monitoring the LINE port status, and left a voicemail but the loopcurrent,vbat and tipringvoltage settings didn't move.
If the stutter got indicated somewhere in the web interface, it could be scrapped.
I'm not aware of any way to accomplish that.
Thanks.
"Selling" this toy at home just got a lot harder.
Dani
I put a voice mailbox at voip.ms (on SP2) on my PSTN line by setting:
Physical Interfaces -> Line Port -> Calling Features ->
CallForwardOnNoAnswerEnabled : checked
CallForwardOnNoAnswerNumber : sp2(0118835100xxxxxxxx)
CallForwardOnNoAnswerRingCount : 5
Where "0118835100xxxxxxxx" is a free iNum DID provided by voip.ms. In the menu at voip.ms DID Numbers -> CallerID Filtering I have a rule for inbound from 0118835100xxxxxxxx to immediately go to the voice mailbox (also on failover conditions Busy, No Answer, and Unreachable). The originating callerid number is lost in the forward to voip.ms (which actually makes this Rube Goldberg work) so I have "say callerid" turned off in the voip.ms mailbox configuration. MWIEnable and X_VMWIEnable are checked on SP2. I turned the answering machine off on the base unit of the cordless system connected to the phone port. I have speed dial #2 set to **2*97 to retrieve voice mail from voip.ms. There is no charge from voip.ms for this forwarding because it's voip.ms DID to DID dialing (the iNum is effectively calling itself.. think about that for a second and it may still not make sense to you, a drink might help). I get the stutter VM waiting sound but I guess my cordless doesn't support the visual indicator. I probably couldn't see the indicator anyway. Since I configure my OBi locally (No, I'm not brainwashed nor a cult member although perhaps newbeeish at times and slowbeeish at others) I have speed dial #1 set to my google voice number because dialing 1# and 2# seems intuitive to me to retrieve VM from SP1 and SP2 respectively. The ObiTalk portal would force speed dial #1 to a soft phone that I don't ever use (unless I'm experimenting).
This method of madness probably (maybe?) could be adapted for use with voip providers other than voip.ms.
It's not exactly what you wanted or needed, but with the OBi, what is?!?
infin8loop: yes, most of it makes sense and seems a good way to restore the natural order of things (at least to the way the phone users here are used to).
The only thing I'm not sure about is why caller id gets lost. Is it because it's an iNum? what if you forward to a sub acct or other kind of virtual sip?
In any case caller id is stored in the Obi history (which I poll and save on an hourly basis)
This may be a good excuse to shave the mailbox from the Bell phone bill. It could even pay for an extra real DID, if that would help in any way.
Thanks for the suggestion.
Quote from: dani on April 13, 2012, 11:39:32 PM
The only thing I'm not sure about is why caller id gets lost. Is it because it's an iNum? what if you forward to a sub acct or other kind of virtual sip?
Dani,
You can retain the caller id if you do the forwarding to voip.ms as a sip uri and you have set X_SpoofCallerID yes in the ITSP Profile for the SPx sip account, for example forward to SP2(5141231234@losangeles.voip.ms) or SP2(5141231234@sip.voip.ms).
Be aware that setting X_SpoofCallerID can cause other problems if you are using the automated attendent (AA) to bridge other calls and your voip provider does not allow a spoofed caller id.
Edit: The reason the caller id gets "lost" is because the call is forwarded by voip. Voip providers require authentication to terminate calls. As part of authentication many/most voip providers who authenticate by userid and password do not allow "spoofed" caller id's. They want to see the caller id that is represented by your account. A few who authenticate by ip address are not that rigid. You can setup a sub account under voip.ms that has an option to authenticate by a static ip address.
When you send a call by sip uri to a voip account it is like a normal incoming call that is not authenticated. I believe that is why you can "spoof" the caller id on the call.
Looks like I have some experiments to do. Thanks all for the suggestions.
For the method I suggested, if the original callerid number is retained then it won't match the iNum filter at voip.ms that sends the call immediately to voice mail. I believe this would create another inbound call back to the OBi and the caller would have to wait longer for that bridged part of the call not to be answered and then be put to voice mail. I have not tested this but this looks like it could be adjusted by fiddling with the voip.ms DID setting "Dial Time Out in seconds" for the iNum which looks to be set at a ridiculous 60 seconds (12 rings. I don't recall setting this but maybe I did). In our case I don't want to set it too low because the iNum is also used for inbound calls by some of my daughter's International friends from summer camp and it needs to be high enough for calls to be answered if there is someone here to answer them. I appreciate the feedback and dialog this has created!
infin8loop,
Looking at the voip.ms offerings, if you wanted to retain the incoming caller id on the forwarded call to voip.ms, I believe you could get a "Virtual SIP Number" from voip.ms and setup routing for all calls to the virtual sip number "DID" to go directly to your voip.ms voicemail. On the OBi you would do your forwarding to the sip uri for your virtual sip number and also on the OBi setup X_SpoofCallerID for your SPx that you will use for the forwarding. I haven't tested this, but I believe it would work.
I think the forwarding to the "virtual sip number" would also be fairly fast.
hwittenb,
The voip.ms "Virtual SIP Number" works great and the callerid is retained on calls sent to the mailbox when using the sip forward. The virtual sip number is just 25 cents a month (less than a penny a day). In this scenario it looks like there is no per minute charge levied. Otherwise It's only 1/10 cent per minute for virtual sip numbers. I noticed the "virtual sip numbers" before but never realized why I would use one. It's always helpful when someone "connects the dots".
Great info. Thanks.
dani,
Hopefully this gives you another option to experiment with. A voip.ms virtual DID URL in the form
sp2(11aaaaaaxxx@servercity.voip.ms) can be substituted for the iNum in my original post where "All virtual numbers consist of the following digits: 11 + Accountcode + 3 digits of your choice for a total of 11 digits.".
Using this method, no CallerID filter is needed at voip.ms. Just configure the virtual SIP DID to go to voice mail immediately.
Been working on this:
Got the virtual sip connected to the mailbox, got the Obi to forward on No Answer. That part works fine.
Also programmed the "VM" button on the phone to dial **2*97. Success so far.
Not so successful:
- Even when ITSP Profile B -> SIP -> X_SpoofCallerID has an X, I still get my own Caller ID. Not sure why...
- just realized that replacing Bell Answering Service with a voip.ms voicemail works fine on NO ANSWER, but not if the PSTN port is BUSY. The ForwardOnBusy only works when the PHONE is busy but the LINE is free.
Far-from-ideal workarounds I can think of:
1) use voip.ms mailbox on busy and bell mailbox on busy (very awkward to manage, plus still paying BELL)
2) do not use the PSTN for outgoing local calls (expensive if going out through voip.ms, caller-id messes up if going out through GV)
Thanks all for your help.
Dani,
You don't have any way to know someone is calling your pstn line when it is busy, only the phone company knows that. Of course you can hire them to forward somewhere on busy but the last time I checked my phone company wanted $7.50/month for that little feature. Another choice is to add call waiting to your pstn line but that also costs money and gets a little complicated pressing the flash to the phone line to answer the call.
You can put your outgoing calls thru a different provider that costs less than voip.ms. Localphone goes for 0.5c per minute. You can set your caller id with them. I don't think their voice quality is quite as good as voip.ms. You can configure both voip.ms and localphone on your adapter using one of the voice gateways for localphone.
As for the caller id on a sip uri call, I don't know what the problem is there. I setup my OBi110 on the Line Port to forward on no answer to a sip uri and I monitored the outgoing voip call packets with WireShark packet trace. The outgoing Sip Invite showed the CallerID in the sip INVITE header field in both the From: and the Remote Party ID: fields. So in my case it is sending it.
Of course the OBi has to receive the incoming caller id from the pstn line. The OBi has a Call History function. When you look at the Call History you should see the incoming call on the Line and the outgoing call for the Call Forward. I initially thought that was a reliable way to tell if the original caller id went out with the forwarded call but it is not reliable. The "Peer Number" shows whether or not it went out with the forwarded call. The "Peer Number" is the incoming caller id. I ran some tests with X_SpoofCallerID on the ITSP Profile B for my SP2 both enabled and disabled and monitored the results with WireShark. That is the setting that does make the difference.
The OBi also has a syslog function that is almost worthless for debugging. It will show, however, if an incoming caller id is detected on an incoming pstn line call on the Line Port, but the Call History also does that.
To run a WireShark trace you need to run the packets thru an old hub, not a switch, with both your pc and you OBi attached so that your pc can see all the packets going to/from the internet. The hub is hard to find if you don't have one.
The plot thickens:
I've been testing this, and found the following:
- the phone NR is overwritten, but the original NAME (if available) is forwarded.
- voip.ms is charging me for the incoming forwarded call. It looks like the Obi transfers the analog call so voip.ms considers it Inbound DID instead of Inbound SIP
- I also tried to forward to sp2(11xxxxx9999@sip.voip.ms) instead of @toronto.voip.ms. The mailbox behaved differently (didn't play my custom msg) and the VMI didn't work.
Are any of these settings related? Do you guys have the defaults on them?:
X_UseRefer
X_ReferAOR
X_Use302ToCallForward
X_InsertRemotePartyID
X_MWISubscribe
X_MWISubscribeURI
Thanks
Dani
Quote from: dani on April 15, 2012, 05:29:27 PMAre any of these settings related? Do you guys have the defaults on them?:
X_UseRefer
X_ReferAOR
X_Use302ToCallForward
X_InsertRemotePartyID
X_MWISubscribe
X_MWISubscribeURI
You should be able to find information on those settings (and the defaults) in the OBi Device Administration Guide (http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf).
Yes, been reading the Admin guide.
Just curious what settings hwittenb and infin8loop had when testing this, in case they were the reason my setup behaves differently.
THanks
Dani,
I goofed. Upon further examination I discovered my initial testing of the voip.ms virtual sip number was not valid. However, in re-testing I do get a valid callerid number in the voip.ms mailbox for calls routed to the voip.ms mailbox by way of Line port CallForwardOnNoAnswerNumber : sp2(11aaaaaaxxx@servercity.voip.ms). There is in fact a charge of .001 (1/10) of a cent per minute for this to happen. The laundry list of Obi parameters you inquired about all have the Default box checked.
I apologize for my confusion. I have two OBi110 units each connected to a different PSTN line and subaccount at voip.ms. Apparently I need to draw myself a diagram of the setup. I hate it whan that happens.
infin8loop
I got the bit about the charge. It's part of the virtual sip.
But... is this (working) setup you describe any different from what we've been testing until now?
I have:
sp2(111xxxxx999@toronto.voip.ms) on LINE CallForwardOnNoAnswerNumber,
LINE CallForwardOnNoAnswerEnable clicked
ITSP Profile B X_SpoofCallerID clicked
It all works, except the forwarding of the CID.
THanks
Quote from: dani on April 15, 2012, 09:01:12 PM
I have:
sp2(111xxxxx999@toronto.voip.ms) on LINE CallForwardOnNoAnswerNumber,
LINE CallForwardOnNoAnswerEnable clicked
ITSP Profile B X_SpoofCallerID clicked
It all works, except the forwarding of the CID.
FWIW, I did some testing and CallerID is definitely passed from SP1. I don't have CallerID service on my PSTN Line, so I can't test it. The settings I used were:
Voice -> Services -> SP1 Service -> CallForwardOnNoAnswerEnable : (checked)
Voice -> Services -> SP1 Service -> CallForwardOnNoAnswerNumber : SP2(1777xxxxxxx@in.callcentric.com)
Service Providers -> ITSP Profile B -> SIP -> X_SpoofCallerID : (checked)
With X_SpoofCallerID enabled, Callcentric receives the CallerID from SP1. With X_SpoofCallerID disabled, it does not. The difference was also obvious in the SIP headers captured with WireShark.
Quote from: dani on April 15, 2012, 09:01:12 PM
infin8loop
I got the bit about the charge. It's part of the virtual sip.
But... is this (working) setup you describe any different from what we've been testing until now?
I have:
sp2(111xxxxx999@toronto.voip.ms) on LINE CallForwardOnNoAnswerNumber,
LINE CallForwardOnNoAnswerEnable clicked
ITSP Profile B X_SpoofCallerID clicked
It all works, except the forwarding of the CID.
THanks
Yes, those are the parameters I have set. Except I use the dallas server, not toronto. I have U.S. AT&T PSTN service. I have the Line Port RingDelay : 2500 (the default is 4000 but 2500 allows the phone to ring faster and still allows the callerid to be obtained. In my case 2000 was too short). If you're getting callerid in the Obi call history on the inbound call, I would think you'd be good to go with whatever you have it set at. Shouldn't matter but I have LINE Port CallForwardOnNoAnswerRingCount : 5.
Another option that came to me. I set up another voip.ms subaccount (I already had 2, one for each Obi). Let's say it's Username aaaaaa_555 and the Internal Extension is 10555 where aaaaaa is the primary account number. Set Internal Extension VoiceMail to the appropriate mailbox. Set the Internal Extension Ringing Time to 1 second (don't think it matters, but it may). Don't register a device to this subaccount.
Then use sp2(10555) on LINE CallForwardOnNoAnswerNumber. It goes directly to voicemail because there's nothing registered to it (and maybe the ring delay of 1 second). This seems to work for me just as well as the virtual sip number. The subaccount is free and there is no per minute charge (not that either would break my bank). Maybe, for whatever reason, you will get callerid in the mailbox using this method since it's an "internal call" and not a sip url.
Dani,
I also did some additional testing sending the forwarded call to the voip.ms sip uri number. The caller id is definetly going out with the settings described however voip.ms is changing it in their CDR records to my voip.ms account setting. I can't figure out why. It's failing some voip.ms test. I'll work trying to find out the reason.
RonR: thanks for checking. It seems my settings are correct.
infin8loop: good idea to try with a subaccount. Will test it during daytime. I always imagined subaccounts needed a registered device to operate.
hwittenb: interesting to know it's not a goof in my setup, but rather something on voip.ms side. Maybe the "reverse" the spoofing?
Thanks all again...
UPDATE:
I tried with a subaccount. It forwarded fine, the billing was 0 as expected, but voip.ms didn't let itself get spoofed.
I checked in 3 places: CDR, email, mailbox readback, and all had the Obi nr. Bummer
I had the following exchange with voip.ms support:
ME:
I programmed my ATA to forward No-answer or Busy PSTN incoming calls to a voip.ms extension connected to a mailbox.
I also programmed the ATA to "spoof" the called id with the info from the incoming call, so the voicemail has the proper caller data.
The forwarding and voicemail works fine, but voip.ms CDR and voicemail shows those forwarded calls and voicemails as being originated by me, instead of the ID of the forwarded call.
Is there a way to modify my settings at voip.ms so the original caller data is recorded?
VOIP.MS:
You will be able to select the Caller ID override, please note that the call forwarding is an outgoing call from our system, so the caller ID displayed will be the one you set on the Caller ID override.
Please check our article here: http://wiki.voip.ms/article/Call_Forwarding
So... nothing new.
Just to try something different, i changed CallForwardOnNoAnswerNumber to tg4(109) and Trunk Group4>TrunkList to sp2. Hoping to be able to have wider syntax options (maybe $1) in the digitmap, but so far haven't found the right setup.
Quote from: dani on April 16, 2012, 11:09:51 AM
Just to try something different, i changed CallForwardOnNoAnswerNumber to tg4(109) and Trunk Group4>TrunkList to sp2.
It's unlikely that using a Trunk Group will help matters. Trunk Groups are simply a way of specifying multiple trunks to use in case one of them is busy.
More testing today. Reviewing my notes from January, at that time, with the settings discussed, I could forward calls to the landline attached to my OBi to voip.ms and they would pickup the original caller id from the forwarded call. Now they do not do that, they substitute. They changed something. I ran some additonal tests using another provider, CallCentric. You can forward sip uri calls to your CallCentric number by using their "Call Treatments". You forward to cc#@in.callcentric.com. If you forward a call to your CallCentric number to your voip.ms virtual number then voip.ms will pickup the original caller id from the call to your CallCentric number. In other words they accept the pass thru by CallCentric.
If you take that a step further and forward (by sip uri) the calls to your OBi attached landline to your CallCentric number which is forward to your voip.ms virtual number then the original caller id is passed thru the chain and accepted by voip.ms.
My conclusion is that voip.ms is looking for something unique to ata's in the Sip Invite sent by OBi's call forwarding that is not contained in Sip Invite sent by CallCentric to voip.ms.
Have you tried using just the voip.ms "Internal Extension Number" associated to the subaccount? Something like sp2(10555) instead of the sip url sp2(aaaaaa555@toronto.voip.ms). Where 10555 is the "Internal Extension Number" associated to subaccount aaaaaa_555 and no device is registered to the subaccount? This of course assumes sp2 on the Obi is registered to voip.ms.
This keeps the inbound callerid id intact for me. But then again, using the virtual sip number in a sip url also works for me as well.
dani, check your "My Messages". I can't guarantee I can get to the bottom of why this doesn't work for you and it works for me. Maybe I'm talking oranges and you all are reading apples. I figure if I start getting spam calls I can just kill the IPKall number. LOL
I need a new hobby. Curling. Yeah, that's it. Curling. That ought to work out just great in Texas. Just shoot me now.
With some more testing I finally got my OBi110 working with an inbound pstn line call simultaneously ringing the voip.ms sip virtual number using the Line Port inbound call routing {SP2(11xxxxxx001@sip.voip.ms),ph} and voip.ms properly picks up the original caller id. When I shifted to using the call forward entries none of them work at all with a number in sip uri format.
Changes I made from the original testing:
1. I could not have SP2 registered to voip.ms. It had to be to someone else.
2. I removed all my caller id override settings on voip.ms (main account, sub_accounts).
3. I repowered the OBi110 (remove power cord, reinsert it).
After I did the above, the caller id function started working correctly with voip.ms. I don't know if they all are really required.
hwittenb:
We did some tests with infin8loop, and realized the caller id override on voip.ms was the culprit. Consistent with your tests too.
Removing it fixes this, but messes up outgoing calls. Now the Obi must pass our own nr to voip.ms. Looking at how to do that.
Haven't gone the fake noanswerforward/delayed forking route yet. First want to see if this method pans out.
Thanks for your help.
Quote from: dani on April 16, 2012, 11:15:56 PMRemoving it fixes this, but messes up outgoing calls. Now the Obi must pass our own nr to voip.ms. Looking at how to do that.
Dani,
I ran some test awhile back and for outgoing calls, most voip providers that authenticate outgoing calls by userid/password do not like spoofed ids for the caller id and as part of the authentication process reject the call. The Betamax companies allowed it, but ignored it and still used what they wanted.
You find a few cases where providers authenticate on your external ip address and might allow spoofed caller ids. Voip.ms has an option on their sub-accounts (sub accounts only) to authenticate by ip address. Of course, if you set this up you either need a static ip address or one that almost never changes. If you have the latter and your ip address changes you need to be aware why your outgoing calls suddenly stopped working.
Dani,
Here is an voip.ms approach that I just tested and at least for now it works.
Setup a new voip.ms subaccount and specify your preferred caller id for outgoing calls, but leave the main account and other subaccounts caller id blank. Make your outgoing calls with this subaccount. I tested it by registering the subaccount under SP2.
Then call forward or use inbound routing for the call forward to your voip.ms main account using a sip uri. The main account doesn't have a substitution caller id specified. I tested using the Line Port inbound routing.
I also tested it by putting the voip.ms subaccount under one of the Gateways and outbound calling thru that. That's what I did first and it worked, so then I tried it directly under SP2.
I'd swear I had almost the same thing yesterday and absolutely wouldn't work this way so something is pretty touchy with voip.ms regarding the settings.
I have an Linksys 2102 hanging on the main acct.
Will move it to a new sub-acct, clean up the setting of the main acct and try again.
It looks like voip.ms is using the contents of these settings in more places than advertised.
Thanks
Quote from: RonR on April 13, 2012, 09:46:14 PM
The OBi doesn't support MWI through the LINE Port.
Is there any fundamental reason why it can't, or is this something that could and should be added?