Unanswered Email

[RonR]

Hi RonR,

We apologize if you have emails to us that remains unanswered.

We will look into all your past emails and will address them if any of them sits unattended.

Thanks for all your timely assistance to our OBi users in the forum, it is much appreciated.

- Obihai support

Still no reply to "DMP Problem" emails dated 7/20 and 8/2 and "pli/Mpli Expansion" email dated 8/7.

[RonR]

Hi RonR,

We apologize if you have emails to us that remains unanswered.

We will look into all your past emails and will address them if any of them sits unattended.

Thanks for all your timely assistance to our OBi users in the forum, it is much appreciated.

- Obihai support

I still have not received a reply to "DMP Problem" emails dated 7/20 and 8/2 and "pli/Mpli Expansion" email dated 8/7.

[RonR]

Hi RonR,

We apologize if you have emails to us that remains unanswered.

We will look into all your past emails and will address them if any of them sits unattended.

Thanks for all your timely assistance to our OBi users in the forum, it is much appreciated.

- Obihai support

Obihai support,

I'm curious why you made these statements but have not followed through.  Since reporting a parsing/matching problem with the OBi's Digit Map Processor on July 5, I have been unable to get a simple reply as to whether you have even been able to reproduce the problem.  I do not understand why you
have ignored my emails and I would appreciate the courtesy of a response.

Ron

[OBiSupport]

Please let us know if you have any additional input to the following clarifications on your requests.

1. DMP: The solution is to use the following Digit map rule: |[^'@'][^'@'].'@'@@.]|
The digit map rule you intended to use is not supported.

2. pli/Mpli Expansion: If you would be so kind as to post this as a feature request, we will evaluate for inclusion in a future software release.

Thank you very much for your continued participation and support!

[RonR]

1. DMP: The solution is to use the following Digit map rule: |[^'@'][^'@'].'@'@@.]|
The digit map rule you intended to use is not supported.

You proposed this solution in the last email I received from you back on 7/15, but as I responded at the time, that rule is not even syntactically correct (it has a mismatched number of brackets).  Using it as is or removing the final bracket (|[^'@'][^'@'].'@'@@.|), the addition of your rule prohibits the dialing of anything (everything gets a busy after a 10 second delay).  I can only assume it was never tested.

You say that the digit map rule I intended (@@.'@'@@.) is not supported.  Would you please explain why and what is wrong with it?  It does, in fact, work absolutely perfectly to match SIP URI's (anything@anything).  The only problem is that its presence causes Star Codes that use the coll(VAR) function to fail (*60, *62, *72, and *74).  Only those four Star Codes are affected and nothing else.  Clearly, there's a bug in your parser.  It amazes me that you don't seem interested in researching and correcting this problem.

2. pli/Mpli Expansion: If you would be so kind as to post this as a feature request, we will evaluate for inclusion in a future software release.

I'm surprised that you would ask me to post this as a feature request when in email exchanges with you back on June 1, you told me you would be able to add this capability in a future release.  What I asked you back on 8/7 (quoting our original exchanges) and got no reply to was if this might be included in the forthcoming v1.3 release.

[RonR]

Please let us know if you have any additional input to the following clarifications on your requests.

1. DMP: The solution is to use the following Digit map rule: |[^'@'][^'@'].'@'@@.]|
The digit map rule you intended to use is not supported.

Obihai support,

You still have not answered any of my questions nor given any explanation, so let me try again.


The rule I intended to use is : @@.'@'@@.

This is a very simple rule :  One or more alphanumeric characters, followed by a literal @, followed by one or more alphanumeric characters

The intended use of this rule is to match SIP URI's : 18005551212@tf.callwithus.com, john_smith@viatalk.com, bob@207.138.76.215, etc.

This rule works properly in that it matches SIP URI's as intended.

The ONLY problem with this rule is that it causes Star Codes *60, *62, *72, and *74 to fail.  These four Star Codes use the script action coll(VAR) described on page 106 of the OBi Device Administration Guide.  No other Star Codes are affected.  No other unintended reactions occur.

This rule conforms to the Digit Map Rules and Elements defined on pages 117, 118, and 119 of the OBi Device Administration Guide.


1. What is syntactically wrong with the rule I intended to use?

2. What aspect of the rule I intended to use causes it to be not supported?

3. Why does the rule I intended to use only affect the four Star Codes which use the script action coll(VAR), but work properly in every other respect?

4. Why is this not a bug?


The rule you provided as the solution is : [^'@'][^'@'].'@'@@.] (or [^'@'][^'@'].'@'@@. assuming the trailing ] was a typo)

This rule is totally unintuitive : One or more characters that are not a literal @, followed by a literal @, followed by one or more alphanumeric characters

This rule cannot be used : It causes the OBi to return a busy signal after a 10 second delay whenever a valid number is dialed.


5. Doesn't the fact that the rule you provided as the solution causes normal dialing to fail further indicate there is a serious bug in the Digit Map Processor?

6. Even if the rule you provided as the solution worked, why would it be necessary to use this totally unintuitive rule instead of the rule I intended to use?

7. Have you tested the rule you provided as the solution to determine whether or not it prohibits dialing valid numbers?


I would appreciate answers to these questions.


If the rule you provided as the solution in fact works for you, I would like to make my OBi available to you for a remote debugging session so that you can determine the source of the problem.

[RonR]

Obihai Technology,

Once again I am having to beg and plead for a response to my questions and requests for technical support.

I feel the seven questions I asked you five days ago after receiving no response to my post nine days ago are fair and reasonable questions.

Why are you unable to provide a response?

[earthtoobi]

ObiSupport Nowadays on the forum has dwindled very much to answer questions.
if there was no Ronr, this would be a relatively in-active forum.

[tome]

This does not bode well for the longevity of the company.  I am reluctant to order further products or to recommend the Obi to others.  If it wasn't for RonR there would be no support whatsoever.  I am also curious about the answers to the questions he has raised. 

Obihai, are you home?

Tom

[OBiSupport]

Hello OBi Supporters,

Thank you for your support, concern and input on the dialog regarding the issue brought up in this thread. We do appreciate the great detail and resourceful suggestions on what may be happening under the hood of the OBi. Know that we normally read each and every forum post within minutes of it appearing for the first time on the OBiTALK forum. It is truly amazing how fast RonR responds to the thousands of users posting topics on the forum. For that, we are greatly appreciative. Also many of you probably do as well, we follow other VoIP user forums so as to gain greater insight as to the current use and suggested enhancement of the platform. About this particular thread -- We are looking into this but find that this is not critical bug. We have suggested some work-arounds about which we hope you can work with us (and you do) to see if there is a solution using the application of different configurations.

We have been working on improving the current products and developing new hardware and software products around which we believe will bring the power of Obihai Technology's platform to more and more consumer residential and small business users and Internet Telephony Service Providers all over the world. Please afford us a more time to study the issue in this thread. Of course, please continue to post and discuss issues here, but also feel free to ask for support via e-mail or open a support request using the form on www.obihai.com/support.html

Thanks again for your support and thank you for your interest in Obihai.

[tome]

Hello OBi Supporters,

Thank you for your support, concern and input on the dialog regarding the issue brought up in this thread. We do appreciate the great detail and resourceful suggestions on what may be happening under the hood of the OBi. Know that we normally read each and every forum post within minutes of it appearing for the first time on the OBiTALK forum. It is truly amazing how fast RonR responds to the thousands of users posting topics on the forum. For that, we are greatly appreciative. Also many of you probably do as well, we follow other VoIP user forums so as to gain greater insight as to the current use and suggested enhancement of the platform. About this particular thread -- We are looking into this but find that this is not critical bug. We have suggested some work-arounds about which we hope you can work with us (and you do) to see if there is a solution using the application of different configurations.

We have been working on improving the current products and developing new hardware and software products around which we believe will bring the power of Obihai Technology's platform to more and more consumer residential and small business users and Internet Telephony Service Providers all over the world. Please afford us a more time to study the issue in this thread. Of course, please continue to post and discuss issues here, but also feel free to ask for support via e-mail or open a support request using the form on www.obihai.com/support.html

Thanks again for your support and thank you for your interest in Obihai.

This is great to hear.   Could someone please address his very specific questions in the last post?  It isn't simply pointing out a bug, it also has to do with syntax and the fact that the workarounds suggested by Obihai support do not work.  I too would like to know the answers...

Thanks,
Tom

[RonR]

Please afford us a more time to study the issue in this thread.

Obihai support,

Another 5 days have elapsed.  No answers to any of the questions I asked have been provided.

Attempting to reproduce the bug I reported in this thread and testing the non-functioning solution you provided cannot possibly take more than 5 minutes each.

Has any progress been made in this area?

[infin8loop]

What we've got here is... failure to communicate.
http://www.youtube.com/watch?v=1fuDDqU6n4o

[R_Chandra]

Actually, although it may be counterintuitive, scanning for non @, then @, then non @ is the more correct pattern.  I encounter this all the time in writing procmail recipes when matching against email addresses.  The problem lies in the fact that the regexp .* includes @ in the match.  So in order to get a proper match, one must scan for anything not an @, the @, and anything after that.  Unless one is trying to prevent double @ in the address, [^@]*@.* will work; [^@]*@[^@]* if one wishes to match an address with ONLY one @.  Knowing nothing more (and I could be wrong), saying "your pattern is not supported" is a way of expressing this, except they don't bother to explain why it might not work.

Your point of it interfering with proper interpretation of star codes still stands though.  Although....consider that non @ also matches *.  Perhaps it could at least be worked around by using [^@*].

But overall, I agree that companies which send nothing more than an automated response/acknowledgement are bad (maybe not terrible, but bad).  Communication, and clear communication at that, is paramount.  Similarly, I really don't like people/companies when they're responding to an email who only answer one of several (related) questions in an email.  It almost forces the sender to send only one question per email to ensure somehow all questions are answered.  They somehow assume the answer they give covers all the questions posed, which very often is not the case.  It's almost as bad as not responding at all.

It also really rubs me the wrong way when replies are put at the top of a message, with the original quoted below (the "Jeopardy!" reply).  This is because it's close to useless beyond the first reply, as it forces people, or especially a newcomer to a thread, to read unnaturally from bottom to top, zigzagging up and down in the process.  The time-honored way of interspersing original quote with reply is a much saner way.  But people are lazy and don't take the time to make it arguably easier on everyone, and instead just start typing wherever their MUA puts their cursor.  They're also disillusioned by the thought that it's best to see the freshest stuff right away, up at the top, but that's a very weak argument IMO.

I'm not saying this necessarily applies to Obihai, but support email in general.

[RonR]

R_Chandra,

Although there are some similarities, the OBi Digit Map syntax is not regexp : OBi Device Administration Guide

Regardless of what you, I, or anyone else feels is intuitive or unintuitive, the fact remains that (@@.'@'@@.) conforms to the documented allowable syntax.  Most importantly, it works perfectly and exactly as expected and intended EXCEPT that it causes the parsing of the Star Code script action 'coll(VAR)' to fail.  This is clearly a bug in the Digit Map Processor and/or the coll(VAR) function parser.

OBihai's response (only after repeated prodding) that "The digit map rule you intended to use is not supported" plus "The solution is to use the following Digit map rule: |[^'@'][^'@'].'@'@@.]|", which isn't even syntactically correct, totally disables the OBi's operation, and couldn't possibly have been tested, wasn't bad, it was insulting.

[R_Chandra]

R_Chandra,

Although there are some similarities, the OBi Digit Map syntax is not regexp : OBi Device Administration Guide

Never said it was...You merely inferred I thought it was.  I was merely stating the fact that I encountered the mentioned difficulty while writing procmail recipes.  Your statement would be akin to me mentioning "although there are some similarities, SIP addresses are not email addresses."

Some references on regexps (e.g. Emacs docs) refer to the greediness of the match, with a postfix operator ("?") to limit the match.  Too bad there doesn't seem to be a digit map analogue.

Regardless of what you, I, or anyone else feels is intuitive or unintuitive, the fact remains that (@@.'@'@@.) conforms to the documented allowable syntax.  Most importantly, it works perfectly and exactly as expected and intended EXCEPT that it causes the parsing of the Star Code script action 'coll(VAR)' to fail.  This is clearly a bug in the Digit Map Processor and/or the coll(VAR) function parser.

...which is why I brought up the possibility that not using [^@] might be including an asterisk, and therefore eating your * codes.  Just because something is expressed syntactically correctly doesn't mean it operates as you expect in all cases with every example of input.  See what I wrote about matching "@" in procmail recipes.  Hmmm...not quite sure if eating * codes conforms to documented behavior or not.  But I'm leaning towards "not."

OBihai's response (only after repeated prodding) that "The digit map rule you intended to use is not supported" plus "The solution is to use the following Digit map rule: |[^'@'][^'@'].'@'@@.]|", which isn't even syntactically correct, totally disables the OBi's operation, and couldn't possibly have been tested, wasn't bad, it was insulting.

On that we can agree thoroughly.  They at least need to provide syntatically correct information, and better still, test their theories before disseminating that information.  Making a typo is not an excuse; they should be copying/pasting from a working config into a message, not rekeying.  Even better, copy/paste from the message back into some device, and test...to make sure nothing was missed in copying from the device and pasting into the message.

Well, in any case...good luck.  I still haven't seen a response to the Opera 11.5x inoperability message I posted.  Thank goodness I'm not dependent at the moment on Obihai fixing that.  Too bad I can't share my fix with everyone else because I would likely be violating their copyright on their (JavaScript) software.

Oh, one other thing I'll add onto this after posting the first time...one thing I did not see the first time around in reading the DM syntax: "The last two elements imply that the OBi digit maps are recursive. [...]. It is important that you do not specify digit maps that lead to infinite recursion. For example, a digit map must not include a named embedded digit map that references itself."  I hate to have to explain to the OBi folks that the very definition of "recursive" is self-reference, whether direct or indirect.  So I'm not sure OBi is so great at communicating in the first place.

[RonR]

Please afford us a more time to study the issue in this thread.

Obihai support,

Another 5 days have elapsed.  No answers to any of the questions I asked have been provided.

Attempting to reproduce the bug I reported in this thread and testing the non-functioning solution you provided cannot possibly take more than 5 minutes each.

Has any progress been made in this area?

Another 14 days have elapsed and no response from Obihai.

[OBiSupport]

The @@.@@ syntax is not supported.  If you can, please use the suggested work-around.

On applying trunking functionality around the mpli/pli substitution capability - this applies per phone and per auto-attendant only.

Thank you again for your support and assistance.

support@obihai.com

[RonR]

Do you even read these posts and emails?  I've put considerable effort into spelling things out in excruciating detail for you, but it appears you haven't bothered to take the time to read any of it.  Let me try once again.

The @@.@@ syntax is not supported.

@@.@@ isn't the syntax there is a problem with or even what's being discussed in the emails and this thread.

@@.'@'@@. is the syntax in question.  You repeatedly say it's not supported, but in fact, it works perfectly with the exception of a very limited undesired side-effect that shouldn't be occurring.  Please explain why it doesn't comply with the syntax rules documented in the OBi Device Administration Guide and isn't supported.

If you can, please use the suggested work-around.

I've repeatedly tried to use your suggested work-around.  If it's used, NO outgoing calls can be made.  I've pointed this out repeatedly in emails and this thread.  Why don't you take five minutes and test it yourself and see that what you suggested totally breaks the OBi.  Regardless of what you dial, there's a 10-second delay followed by a fast busy.

On applying trunking functionality around the mpli/pli substitution capability - this applies per phone and per auto-attendant only.

I know that mpli/pli substitution is currently only applied to the PHONE Port and Auto Attendant DigitMap and OutboundRoute.  I exchanged numerous emails with you explaining why it makes sense to apply it to the InboundCallRoute also.  You agreed and said you could do it.  Why you now have amnesia is a mystery.

[OBiSupport]

Do you even read these posts and emails?

Yes.  We read your posts and e-mails.  We really appreciate the thought and effort you expend to help the OBi user community.

I've repeatedly tried to use your suggested work-around.  If it's used, NO outgoing calls can be made.

As the suggested work-around does not work for your application, there is no solution.

You agreed and said you could do it.  Why you now have amnesia is a mystery.

Here, we are stating the current functionality.  At this time, there is no date as to when the current functionality will be modified.

Thank you your support.