Using # in DigitMap for routing to SIPToSis gateway is not working. - SOLVED

[shap]

Hello,

I have a strange problem - I changed my Linksys PAP2T to Obi110.
I am also using a Skype gateway (SIPToSis) and my dial plan on Linksys was:

(<#1:>xx.<:@192.168.1.101:5070>|*xxxxS0|<:02>xxxxxxx|0[5-7]xxxxxxxxS0|0[2-48-9]xxxxxxxS0|<00:014>x.|<012:014>x.|<013:014>x.|xx.|*xx.)

So to get the same result on Obi110 I did the following:
1. Phone -> DigitMap: ([1-9]x?*(Mpli)|**0|***|#|**1(Msp)|**2(Msp2)|**8(Mli)|**9(Mpp)|#1(Mvg1)|(Mpli)|**3(Mvg1))

2. Phone-> OutboundCallRoute: {([1-9]x?*(Mpli)):pp},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(<#1:>(Mgv1)):vg1},{(<**3:>(Mvg1)):vg1},{(Mpli):pli}

3. VoiceGateway1 -> AccessNumber: sp1(192.168.1.101:5070)
   VoiceGateway1 -> DigitMap:(xx?)
   VoiceGateway1 -> AuthUserID: 767657657

With Linksys I was dialing : #133 for example to get some user in Skype. This is not working with Obi110. However, if I use **333 - call passed to SiptoSis w/o a problem.

It seems that #1 pattern is recognized by the Obi but as far as I see it tries to dial @192.168.1.101:5070. and fail. With using **3 it is dialing 33@192.168.1.101:5070.

I do not know if it is a bug or feature, but I did no find any reference that I can not map #....

[RonR]

Using a '#' in a DigitMap/OutboundCallroute is supposed to be allowed.  I can reproduce the problem you're experiencing.


There appears to be two problems occurring here:

1.  Things are getting tangled up with this rule: {(<#:>|911):li}

2. Removing the rule cited above, the OBi tries to send the call out SP1 (Google Voice) instead of the intended SP2 (VoIP) in my case.


When I first got my OBi, I discovered a number of problems with DigitMap/OutboundCallRoute parsing that were ultimately corrected.  It would appear you've found yet another.

[obi-support2]

You have a typo in your OutboundCallRoute: {(<#1:>(Mgv1)):vg1}

I think you meant {(<#1:>(Mvg1)):vg1}

With this change, it works as expected.

Ans the answer is yes, you can use #1, #2, etc. for call routing, just like **1, **2, ...

[RonR]

**2 Works:

PHONE Port DigitMap:

([1-9]x?*(Mpli)|[1-9]x?|911|**0|***|#|**1{t=di2}(Msp1)|**2{t=di2}(Msp2)|**3{t=di2}(Mvg3)|
**4{t=di2}(Mvg4)|**6{t=di2}(Mvg6)|**7{t=di2}(Mvg7)|**8{t=di2}(Mli)|**9{t=di2}(Mpp)|(Mpli))


PHONE Port OutboundCallRoute:

{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},
{(<**2:>(Msp2)):sp2},{(<**3:>(Mvg3)):vg3},{(<**4:>(Mvg4)):vg4},{(<**6:>(Mvg6)):vg6},
{(<**7:>(Mvg7)):vg7},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}



#2 Fails:

PHONE Port DigitMap:

([1-9]x?*(Mpli)|[1-9]x?|911|**0|***|#|**1{t=di2}(Msp1)|#2{t=di2}(Msp2)|**3{t=di2}(Mvg3)|
**4{t=di2}(Mvg4)|**6{t=di2}(Mvg6)|**7{t=di2}(Mvg7)|**8{t=di2}(Mli)|**9{t=di2}(Mpp)|(Mpli))


PHONE Port OutboundCallRoute:

{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},
{(<#2:>(Msp2)):sp2},{(<**3:>(Mvg3)):vg3},{(<**4:>(Mvg4)):vg4},{(<**6:>(Mvg6)):vg6},
{(<**7:>(Mvg7)):vg7},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}


The only change is:  **2  ->  #2

In the #2 failure case (#218005551212), a second dialtone is presented after '#2' is dialed, but the LINE Port is selected as if nothing but '#' was dialed (regardless of whether a terminating '#' is used or not).

The call history shows PHONE1 Peer Number: #218005551212 on the left and LINE1 with no Peer Number on right.

I don't think I have a typo.

[obi-support2]

Ron,

I was replying to shap. I thought you were testing his callroute also?
His case is all working by fixing the typo: (Mgv1) is undefined; it should be (Mvg1).
It looks to me a typo anyway.

-----

Your new cases I can reproduce also; removing "<#:>|" from {(<#:>|911):li} should make it work too.
We are looking at why #1 etc will cause conflict in this case; it shouldn't.

[RonR]

obi-support2,

Let me give you a simple test case.

With PHONE Port DigitMap and OutboundCallRoute at defaults, dial #123#.  It should get an invalid number response, but it selects the LINE Port.  Dial # + anything, with or without a terminating #, and the LINE Port is selected.

[earthtoobi]

when using SIptoSIS is there a way to make the computer not ring along with the telephone attached to Obi.when you answer the call using telephone, computer speaker and mic also get turned on.

[RonR]

2. Removing the rule cited above, the OBi tries to send the call out SP1 (Google Voice) instead of the intended SP2 (VoIP) in my case.

obi-support2,

This item I quoted above isn't actually a problem in the OBi.  I was doing my testing by tacking a test case onto the end of my rules.  As I'm sure you're aware, it's important that the {(Mpli):pli} rule be at the end of the OutboundCallRoute as it often matches things you didn't really intend due to the xx. in ITSPx DigitMaps.  I forgot this for a moment and that's why my call went out SP1 instead of VGx(sip) via SP2, seemingly by mistake.

If you fix the problem with <#:>, things may be OK at that point.

[shap]

Ron,

I was replying to shap. I thought you were testing his callroute also?
His case is all working by fixing the typo: (Mgv1) is undefined; it should be (Mvg1).
It looks to me a typo anyway.
-----
Your new cases I can reproduce also; removing "<#:>|" from {(<#:>|911):li} should make it work too.
We are looking at why #1 etc will cause conflict in this case; it shouldn't.

Thank you - you are correct, sorry for this typo and obsolete question. Fixing the typo indeed fixed the problem and it is working ok now. Thank you all for your effort.

[shap]

when using SIptoSIS is there a way to make the computer not ring along with the telephone attached to Obi.when you answer the call using telephone, computer speaker and mic also get turned on.

Unfortunately not - in my case it is an old laptop that serves me as a server. I turned off the speakers on this laptop. You may consider to use vmware on your main computer that can do the SipToSis work and turn off the speakers there (did not tried myself, but should work I think).