3 POTS lines with 2 stepping DIDs

Discussion in 'General' started by yesmat, Nov 4, 2009.

  1. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    Hi,

    I have an interesting issue that could be due to misconfiguration of Elastix server or could be due to Dahdi driver issue.

    Setup:

    1- Elastix 1.5.2 with Openvox A400P card with 3 FXO ports.
    2- The card is connected to 3 POTS lines.
    3- Over these POTS lines there are 2 DIDs that are configure to step across these 3 lines if they are busy as follows: line1 -> line2 -> line3
    4- A single inbound route "ANY/ANY" is configured to send all inbound calls to the same IVR, which is working good, no problems so far.

    Customer request:

    Customer wants to start diverting all inbound calls destined to DID1 to IVR1, while calls destined to DID2 to IVR2.

    Problem:

    Asterisk server can't see DID numbers for any of the inbound calls hence unable to differentiate between the different calls.

    Telco confirms that they ahve configured DIDs to be forwarded for all inbound calls.

    Under FreePBX => Setup => Zap Channel DIDs there are no configuration at all. Reason for that is this is meant for statically configuring specific channels to specific DIDs, but when your DIDs step across all lines then this area of configuration becomes useless.

    Any one has come across this before? any advice?

    thanks
     
  2. Bob

    Bob

    Joined:
    Nov 4, 2007
    Messages:
    2,400
    Likes Received:
    1
    yesmat,

    Traditional analog lines are one number for each line.

    Line Hunt allows callers to call the prime number, and based on a pattern you and your carrier have implemented, the exchange cascades the number if it finds the prime number busy or any of the subsequent cascaded numbers busy.

    On standard traditional analog lines, DID information is not transmitted down analog lines. CID information however is transmitted down analog lines but as you know, this is the callers number, not the number that they dialled to reach you (DID).

    E1/T1/BRI lines do have this capability, but with an analog card, you don't

    So this is where the Zap Channel DID's in Freepbx comes into play allowing you to map a channel to a DID for the purposes of inbound routing.

    Now the feature you refer to is called analog DID, but it is not common as there is no fixed standard for this method, it can be done via Wink. done by DTMF, and other such methods. I know that over the last few years (especially with many wanting that feature moving to BRI or PRI), most carriers have been removing it from their offerings (not that it is that popular nowadays), especially as they upgrade or implement exchange equipment that does not offer that facility.

    I have not checked, but I don't believe that the Dahdi/TDM4xx support that feature anyhow, for the similar reason, with no standard to rely on.

    So to answer your question, unless you leave a line or two off the line hunt, and implement DID Zap channel mapping, you have no way of implementing this.

    Regards

    Bob
     
  3. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    Hi Bob,

    Thanks for your detailed reply.

    One thing I know for sure is that Telcos in our part of the world do offer numbers (DIDs) that do step across Analouge lines (Line Hunting). I believe they use in-band DTMF to deliver that.

    The strange thing is that none of the Openvox engineers ever mentioned, after I sent for help, that their Analogue A400P card doesn't support that feature. Maybe they are trying to figure out what standard our telco is using to configure the Dahdi driver accordingly.

    The problem is if we take these lines off the hunting then it becomes "one number/one line" and if the line is busy no more calls are able to go through untill the line is cleared, which is not acceptable for busness usage.

    Will have to wait and see what openvox come back with, maybe they have a solution.

    Cheers
     
  4. Bob

    Bob

    Joined:
    Nov 4, 2007
    Messages:
    2,400
    Likes Received:
    1
    I have had a brief look to see if I can find any mention of handling DID information on analog lines in with Zaptel/dahdi, with no luck.

    I am going to have a better look later on because you have me intrigued. :blink:

    Regards
    Bob
     
  5. briankelly63

    Joined:
    Oct 28, 2009
    Messages:
    19
    Likes Received:
    0
    Perhaps a different approach.... what if you forward the analog lines to DID SIP trunks. I forward two local POTS lines to numbers I have with Vitelity (considered local call based on DID number selection) which puts the incoming calls into the VOIP world, restores caller-id, allows multiple calls to come in through each analog line based on the number of channels I have with Vitelity and since I know which analog line forwards to which Vitelity DID I can route them as needed...

    You can still use the outgoing Zap channels on those lines if you need to.


    Just a thought...

    Brian
     
  6. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    I can't agree with that forwarding thing, it would likely incur an outbound call cost per inbound call from his telco, my experience with analog DID's (for me, here in the US, CA specifically, where the PUC has mandated toll on all business local calls, wherein analog DID would definitely fall), is that these analog did trunks are inbound only and use MF signaling, by the sound of it this telco is perhaps emulating the standard E&M analog DID behavior with some inline DTMF signaling where the last n digits are sent after the call is answered, and before any CID is sent (if at all, because that would need interstitial winks or something and be very confusing as bob said). Setting the DTMF logging in /etc/asterisk/logger.conf , e.g.

    full => notice,warning,error,debug,verbose,dtmf

    (and a rasterisk -x "logger rotate" to set it)

    will expose any in-band analog dtmf signaling apparent on the connection (in /var/log/asterisk/full), as yesmat suspects is happening. (never heard of that, but it would work in theory) if the signaling is MF or perhaps FSK (not DTMF) then all bets are off.

    JM2CWAE

    (To which country do you belong Yesmat ?, I am also intrigued)
     

Share This Page