News:

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

Main Menu

DigitMap - recursiviness

Started by Obvdobi, October 23, 2011, 11:06:35 AM

Previous topic - Next topic

Obvdobi

On Obi's administration guide, it mentioned DigitMap's recursiveness.  So, should it be okay to rewrite this rule

from:
Quote(1xxxxxxxxxx|<1615>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|<0:**201186>1[02-9]xx.|<0:**201186>[2-9]xx.|<**2>011xx.|<00:**2011>xx.|xx.|(Mipd)|[^*]@@.)
to:
Quote(1xxxxxxxxxx|<1615>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|<0:01186>1[02-9]xx.|<0:01186>[2-9]xx.|<00:011>xx.|<**2>011xx.|xx.|(Mipd)|[^*]@@.)
?

RonR

Assuming this is your PrimaryLine/SP1 DigitMap, only calls to 011+ will be diverted to SP2 using the second DigitMap.

You didn't implement any recursion anywhere.  You simply removed three **2 redirects.

Obvdobi

I tried, it seems the digits are translated properly. However, the lines are not.

Using the first DIGITMAP, it will automatically switch to SP2 to dial out international number.

Using the second digitmap, the number is translated to '**201186.....', but it still uses SP1 to dial out the international number as is: "**201186...".


RonR

Using the second DigitMap...


Service Provicers -> ITSP Profile A -> General -> DigitMap:

(1xxxxxxxxxx|<1615>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|<0:01186>1[02-9]xx.|
<0:01186>[2-9]xx.|<00:011>xx.|<**2>011xx.|xx.|(Mipd)|[^*]@@.)


Any number matching either the <0:01186>1[02-9]xx. or <0:01186>[2-9]xx. rule will be transformed to 01186+ during the DigitMap evaluation phase of the call from the PHONE Port.  During the OutboundCallRoute evaluation phase of the call from the PHONE Port, the 01186+ will match the {(Mpli):pli} rule (which the OBi has internally rewritten to {(Msp1):sp1} since the PrimaryLine is SP1) which will add **2 before sending the call out SP1.

The two-stage (DigitMap + OutboundCallRoute) aspect of PHONE Port call processing can be a little tricky.

Obvdobi

Hmm, how to properly implement a recursiveness? I probably misunderstood how it works.

I thought the second digitmap works like this:

  • dial 010-5555-5555
  • the rule translate it to 011861055555555
  • Then the rule will see it start with 011 and translate it into **2011861055555555

Here is what happened when dialing out 010555555555, primary line is SP1 (google voice):
 Using the first digitmap:
   Terminal ID   PHONE1   SP2
       Peer Number   **2011861055555555   => 011861055555555
 Using the second digitmap:
   Terminal ID   PHONE1   GoogleVoice1
       Peer Number   011861089529702   =>  **2011861055555555

Obvdobi

This is exactly what happened.  I am still trying to wrap my head around the concept of the two stage process. Since translation in either phase using SP1's digitmap adds '**2' , is there a place to let it do a recursive mapping thru the same rule to go to SP2?

Quote from: RonR on October 23, 2011, 11:41:04 AM
Using the second DigitMap...


Service Provicers -> ITSP Profile A -> General -> DigitMap:

(1xxxxxxxxxx|<1615>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|<0:01186>1[02-9]xx.|
<0:01186>[2-9]xx.|<00:011>xx.|<**2>011xx.|xx.|(Mipd)|[^*]@@.)


Any number matching either the <0:01186>1[02-9]xx. or <0:01186>[2-9]xx. rule will be transformed to 01186+ during the DigitMap evaluation phase of the call from the PHONE Port.  During the OutboundCallRoute evaluation phase of the call from the PHONE Port, the 01186+ will match the {(Mpli):pli} rule (which the OBi has internally rewritten to {(Msp1):sp1} since the PrimaryLine is SP1) which will add **2 before sending the call out SP1.

The two-stage (DigitMap + OutboundCallRoute) aspect of PHONE Port call processing can be a little tricky.


RonR

#6
Quote from: Obvdobi on October 23, 2011, 11:53:33 AM
Since translation in either phase using SP1's digitmap adds '**2' ...

Assuming we're still talking about your second DigitMap...

During phase 1 (the DigitMap evaluation phase), only calls beginning with 011 will have **2 added.  A 010-5555-5555 call will be transformed to 01186 but **2 will NOT be added.  During phase 2 (the OutboundCallRoute evaluation phase), the **2 will be added as it's being sent out SP1.

Using the first DigitMap, **2 will be added during the DigitMap evaluation phase as well as transforming a 010-5555-5555 call to 01186.  Then during the OutboundCallroute evaluation phase, the **2 will be removed when the {(<**2:>(Msp2)):sp2} rule matches and sends the call out SP2.

RonR

Quote from: Obvdobi on October 23, 2011, 11:41:29 AM
Hmm, how to properly implement a recursiveness? I probably misunderstood how it works.

Generally, something is recursive when it references itself.  For example:

Service Providers -> ITSP Profile A -> General -> DigitMap : (1xxxxxxxxxx|(Msp1))

This DigitMap would be catastrophic to use as it creates an endless loop which would crash the OBi.

While the DigitMap Processor (DMP) function in the OBi is almost certainly implemented as a recursive subroutine, using recursion in a DigitMap would be very rare and would require extreme care to avoid an endless loop.

What's used frequently is nested DigitMaps.  For example:

Service Providers -> ITSP Profile A -> General -> DigitMap : (Mste)

User Settings -> User Defined Digit Maps -> User Defined Digit Map2:

Label: ste
DigitMap: (1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1870>[2-9]xxxxxx|011xx.|(Mipd)|[^*]@@.'@'@@.)

User Settings -> User Defined Digit Maps -> User Defined Digit Map1:

Label: ipd
DigitMap: (xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?|xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?<*::>xx?x?x?x?)

Obvdobi

Cool. You explained it quite clearly.  Thanks. I guess the only part I can extract from the current DigitMap is the US based numbers. For international number, it will still be somewhat separate among SP1, SP2, Obi, AA.

Thanks to the great resources of the board and your help,  my Obi110 is pretty much what I want it to be at the moment.  What's great is your single-step dialing setup, I can add any friend or family member with ObiON app on iPhone /iPad to use my device to dial any US, China and international number in its local format.

Quote from: RonR on October 23, 2011, 01:04:58 PM
Quote from: Obvdobi on October 23, 2011, 11:41:29 AM
Hmm, how to properly implement a recursiveness? I probably misunderstood how it works.

Generally, something is recursive when it references itself.  For example:

Service Providers -> ITSP Profile A -> General -> DigitMap : (1xxxxxxxxxx|(Msp1))

This DigitMap would be catastrophic to use as it creates an endless loop which would crash the OBi.

While the DigitMap Processor (DMP) function in the OBi is almost certainly implemented as a recursive subroutine, using recursion in a DigitMap would be very rare and would require extreme care to avoid an endless loop.

What's used frequently is nested DigitMaps.  For example:

Service Providers -> ITSP Profile A -> General -> DigitMap : (Mste)

User Settings -> User Defined Digit Maps -> User Defined Digit Map2:

Label: ste
DigitMap: (1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1870>[2-9]xxxxxx|011xx.|(Mipd)|[^*]@@.'@'@@.)

User Settings -> User Defined Digit Maps -> User Defined Digit Map1:

Label: ipd
DigitMap: (xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?|xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?<*::>xx?x?x?x?)