CallerID inconsistently presented through ISDN/cellular networks

Home » Asterisk Users » CallerID inconsistently presented through ISDN/cellular networks
Asterisk Users 16 Comments

Hi,

I’m still strugling with my CallerID presentation problem.
Let me remind it :

My setup is:
Alice cellphone < --GSM-->< --ISDN--> Asterisk < -- ISDN -->< --GSM--> Bob
cellphone

Ive configured Asterisk so that whenever Bob forwards its incoming call to
its cellphone, the later phone should present Alice’s number.

I was originally told that sometimes Bob would be presented Alice’s number,
sometimes the dialed number (which in this case, also match the ANI or the
receptionnist ID).
Now, I can’t certify this ever happened : maybe, it did happen, maybe not.

What I can certify is this:
1. out of 32 different callers, 20 callers are presented with the correct
number and 12 with the dialed number,
2. all those 32 callers are cellphones operated by the same (incumbent)
telco which also operates ISDN,
3. Bob’s cellphone is also operated by the same (incumbent) telco,
4. all this tries were done the same day, one after the other.

The best explanation I can think of is this:
“Depending on the route used, the ANI is used instead of the presented
caller ID”.

To prove that, I’ll try to “record” 2 calls for the same caller and toward
the same destination: one with the awaited presentation, one with a wrong
one.
(Sending this to the telco and have them change anything is an other story).

Comments and suggestions are welcome.

Regards

16 thoughts on - CallerID inconsistently presented through ISDN/cellular networks

  • What version of Asterisk? Is the forwarding done using Followme, attended
    transfer or blind transfer?

    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olivier
    Sent: Thursday, November 03, 2011 8:14 AM
    ISDN/cellular networks

    Hi,

    I’m still strugling with my CallerID presentation problem.
    Let me remind it :

    My setup is:
    Alice cellphone < --GSM-->< --ISDN--> Asterisk < -- ISDN -->< --GSM--> Bob
    cellphone

    Ive configured Asterisk so that whenever Bob forwards its incoming call to
    its cellphone, the later phone should present Alice’s number.

    I was originally told that sometimes Bob would be presented Alice’s number,
    sometimes the dialed number (which in this case, also match the ANI or the
    receptionnist ID).
    Now, I can’t certify this ever happened : maybe, it did happen, maybe not.

    What I can certify is this:
    1. out of 32 different callers, 20 callers are presented with the correct
    number and 12 with the dialed number,
    2. all those 32 callers are cellphones operated by the same (incumbent)
    telco which also operates ISDN,
    3. Bob’s cellphone is also operated by the same (incumbent) telco,
    4. all this tries were done the same day, one after the other.

    The best explanation I can think of is this:
    “Depending on the route used, the ANI is used instead of the presented
    caller ID”.

    To prove that, I’ll try to “record” 2 calls for the same caller and toward
    the same destination: one with the awaited presentation, one with a wrong
    one.
    (Sending this to the telco and have them change anything is an other story).

    Comments and suggestions are welcome.

    Regards

  • Something like this?
    [callbob]

    Exten => start,1,answer

    Exten => start,n,Dial(DAHDI/1/5551212,30)

    If that is the case, Bob should always get the Caller ID of your asterisk
    installation – I would suggest this instead

    [callbob]

    Exten => start,1,answer

    Exten => start,n,Set(CALLERID(num)=${EXTEN})

    Exten => start,n,Dial(DAHDI/1/5551212,30)

    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olivier
    Sent: Thursday, November 03, 2011 8:33 AM
    ISDN/cellular networks

    2011/11/3 Danny Nicholas

    What version of Asterisk?

    1.6.1.18

    Is the forwarding done using Followme, attended transfer or blind
    transfer?

    a plain Answer plus Dial

    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olivier
    Sent: Thursday, November 03, 2011 8:14 AM
    ISDN/cellular networks

    Hi,

    I’m still strugling with my CallerID presentation problem.
    Let me remind it :

    My setup is:
    Alice cellphone < --GSM-->< --ISDN--> Asterisk < -- ISDN -->< --GSM--> Bob
    cellphone

    Ive configured Asterisk so that whenever Bob forwards its incoming call to
    its cellphone, the later phone should present Alice’s number.

    I was originally told that sometimes Bob would be presented Alice’s number,
    sometimes the dialed number (which in this case, also match the ANI or the
    receptionnist ID).
    Now, I can’t certify this ever happened : maybe, it did happen, maybe not.

    What I can certify is this:
    1. out of 32 different callers, 20 callers are presented with the correct
    number and 12 with the dialed number,
    2. all those 32 callers are cellphones operated by the same (incumbent)
    telco which also operates ISDN,
    3. Bob’s cellphone is also operated by the same (incumbent) telco,
    4. all this tries were done the same day, one after the other.

    The best explanation I can think of is this:
    “Depending on the route used, the ANI is used instead of the presented
    caller ID”.

    To prove that, I’ll try to “record” 2 calls for the same caller and toward
    the same destination: one with the awaited presentation, one with a wrong
    one.
    (Sending this to the telco and have them change anything is an other story).

    Comments and suggestions are welcome.

    Regards

  • Trying to save a few keystrokes – better example
    [callbob]

    Exten => _XX.,1,answer

    Exten => _XX.,n,Dial(DAHDI/1/5551212,30)

    If that is the case, Bob should always get the Caller ID of your asterisk
    installation – I would suggest this instead

    [callbob]

    Exten => _XX.,1,answer

    Exten => _XX.,n,Set(CALLERID(num)=${EXTEN})

    Exten => _XX.,n,Dial(DAHDI/1/5551212,30)

  • When you say 2/3 of calls, is there an inconsistency to the same recipient
    or could it be a carrier issue (Verizon only, T-Mobile only, etc.)?

    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Olivier
    Sent: Friday, November 04, 2011 3:33 AM
    ISDN/cellular networks

    2011/11/3 Danny Nicholas

    [callbob]

    Exten => _XX.,1,answer

    Exten => _XX.,n,Set(CALLERID(num)=${EXTEN})

    Exten => _XX.,n,Dial(DAHDI/1/5551212,30)

    From memory, I did it this way :
    Exten => _XX.,1,Set(CALLERID(num)=whatever)
    Exten => _XX.,n,answer
    Exten => _XX.,n,Dial(DAHDI/1/5551212,30)

    This seems to work for roughly 2/3 of calls.
    I’m trying to get as close to 100% as possible.

    I can’t think of any configuration issue or bug in Asterisk that would cause
    1/3 of calls to be incorrectly presented.
    I rather suspect that different calls MAY use different routes and a
    misconfiguration in one equipement in one of those would cause the issue.

    I don’t know how Telcos manage their networks.
    I would have naturally thought that going from one point to another in this
    network would always pass through the same set of equipements.
    Maybe it’s not the case and specifically when the end destination is a
    cellphone and there is a large gateway between the landline and the mobile
    networks.

    Is this reasonning correct ?

  • 2011/11/4 Danny Nicholas

    When we tested, calls were originated by 32 different cellphones to a
    unique ISDN-connected Asterisk box which then forwarded this call to a
    unique destination cellphone.
    Naming things this way “A calls B which forwards to C”, we used 32
    different cellphones as A, and only one asterisk and one cellphone as
    respectively B and C.

    A doubt I still get at the moment, is I can’t swear B always received a
    correct CallerID from A (maybe, it received 32 correct Caller IDs, maybe
    not).
    That’s why I’m gonna try again this weekend to record full logs of calls
    leaving Asterisk to the destination cellphone.

    Asterisk and cellphones are connected to each other with France Telecom
    ISDN and GSM networks.

  • Il 04/11/2011 9.32, Olivier ha scritto:

    It was … about 30 (or more) years ago, today most moved from switched
    network to packet network.

    I think most is carried on ss7(*) over ip, passing through a wide range
    of equipments from many manufacturers. Each of these could have it’s own
    bugs or inaccurate configuration.

    I think it is, you are facing some internetwork problem out of your control.

    Anyway you’re lucky, changing the caller presentation number to anything
    that not belongs to the subscriber circuit would be simply impossible
    here due to regulations.

    (*) – http://www.ss7-training.net/index.html

  • Hi,

    As promised, here is a follow up on my quest to get CallerID correctly
    presented when forwarding calls to cellphones.

    Here is a reminder of the issue at hand:

    Alice (GSM handset) calls Bob (ISDN-connected Asterisk extension) which
    forwards to Cory (GSM handset)
    What I would like to get is to see Alice’s number (not Bob’s number)
    presented to Cory.
    Sometimes, I get Alice’s number, sometimes, I get Bob’s number (new
    findings from last sunday trials).
    And of course, if Daniel or Eric would call Bob, the CallerID number
    presented to Cory would either be Daniel’s number, Eric’s number or Bob’s
    number depending on a root cause I’m looking after for several days now.

    To check if CallerID is filtered or controlled by Telco, I originated calls
    from Asterisk using hand crafted caller ids: any CallerID was correctly
    presented.
    So I originally thought the root cause I’m after is a telco equipment
    switching ANI and CID.
    But a close look at some last trials output makes me asking for opinions
    from this list readers.

    Here follows, the anonymized (and hand indented) output of command PRI
    debug command.
    I focused on the end of call setup dialog.

    For the successfully presented call, the output is:
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [6c 0b 21 83 37 38 36 XX
    XX XX XX XX XX]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Calling Number (len=13) [
    Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
    (E.164/E.163) (1)
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: >
    Presentation: Presentation allowed of network provided number (3)
    ‘78649XXXX’ ]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [70 0b 80 30 36 37 31 XX
    XX XX XX XX XX]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Called Number (len=13) [
    Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
    ‘067100XXXX’ ]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [74 0e 21 01 8f 33 33 33
    34 34 XX XX XX XX XX XX]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Redirecting Number
    (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering
    Plan (E.164/E.163) (1)
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c:
    permitted, user number passed network screening (1)
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c:
    (15)
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: ‘3334436XXXX’ ]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > [a1]
    [Nov 6 09:32:07] VERBOSE[27954] chan_dahdi.c: > Sending Complete (len= 1)

    For the unsuccessfully presented call, the output is:
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [6c 0b 21 83 36 37 38 XX
    XX XX XX XX XX]
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Calling Number (len=13) [
    Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
    (E.164/E.163) (1)
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: >
    Presentation: Presentation allowed of network provided number (3)
    ‘67854XXXX’ ]
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [70 0b 80 30 36 37 31 XX
    XX XX XX XX XX]
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Called Number (len=13) [
    Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
    ‘067100XXXX’ ]
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > [a1]
    [Nov 6 09:25:29] VERBOSE[27927] chan_dahdi.c: > Sending Complete (len= 1)

    Am I correctly interpreting when saying that in the successful call,
    Asterisk is sending a [74 0e 21 01 8f 33 33 33 34 34 XX XX XX XX XX XX]
    message which is not otherwise sent ?
    What can explains this difference ?
    Is this something I can (should) control ?

    For reference:
    dahdi show version
    DAHDI Version: SVN-trunk-r8853M Echo Canceller: OSLEC
    pri show version
    libpri version: 1.4.10.2

    Regards

  • 2011/11/8 Richard Mudgett

    Hi Richard,

    1. Could you elaborate a bit ?
    Do you imply that the lines bellow were present (or missing) because I did
    somewhere set CALLERID(RDNIS) and that I should use them ?

    2. More generally, if I may ask, how do you understand both outputs (from
    my previous post) ?

    Regards

  • No. I was trying to say that the value in the redirecting ie is
    controllable by setting/clearing the CALLERID(RDNIS) value.

    Since you are not changing the value of RDNIS, then the RDNIS value
    came in from the telco. The presence of the RDNIS value on the incoming
    call implies that the call has already been redirected at least once.

    The first example (working):
    I am interpreting the numbers as belonging to:
    Party A is the calling number
    Unknown party or Party B is the redirecting number
    Party C is the called number

    The second example (not working):
    I am interpreting the numbers as belonging to:
    Party A?? is the calling number
    (guessing here. It is either the calling number of the incoming
    call or your dialplan has set it with CALLERID(num).)
    Party C is the called number

    The information here suggests that you should try setting CALLERID(RDNIS) to
    party B and dialing. This would make the not working call look like the
    working call for your call forwarding case.

    Richard

  • 2011/11/8 Richard Mudgett

    Thanks for this enlightment.

    I can confirm CALLERID(RDNIS) is not explicitely changed within the
    Asterisk server.
    The choosen format like 3334436XXXX is noticeable (the system is installed
    in France where numbers are in this +33(0)123456789 shape).

    It seems that sometimes, calls come in with this CALLERID(RDNIS) value set
    and sometimes not, though all of them where direct.

    I agree that setting CALLERID(RDNIS) myself is definitively worth trying.

    1. Would you expect CALLERID(RDNIS) to be implicitely changed within the
    Asterisk server ?
    This page (http://www.voip-info.org/wiki/view/RDNIS) suggest this to be
    true (“The Dial application also sets the RGN to the current extension”)
    and suggest CALLERID(RDNIS) to be overwritten by Dial.

    2. As I feel specically new to this RDNIS concept, how should I set
    CALLERID(RDNIS), before or after Answer() statement ?

    Cheers

  • Asterisk will not normally change the RDNIS value received. That web
    page does not state why the dial application sets RDNIS which can be
    confusing. The only time RDNIS is set is if the outgoing call is itself
    redirected/forwarded by the peer. For Asterisk v1.6.1 the only channel
    drivers that support this are SIP and skinny.

    It does not matter in this case. Asterisk v1.6.1 will keep both legs
    of the call anyway.

    If you ultimately want to get the call entirely off of your Asterisk
    server, you will need Asterisk v1.6.2 or later. You would also need
    libpri 1.4.12 to do this with ETSI(EuroISDN). You would then use
    the DAHDISendCallreroutingFacility application *before* you answer
    the call to forward/deflect the incoming call back to the network.

    Richard

  • Hello,

    Revisiting this old thread, following Richard’s suggestion, I modified
    Asterisk config so that it would set RDNIS for every forwarded call.

    I kept at hand, the results gathered in another test session :
    the output of a “successful” call (with appropriate CallerID) and the
    output of an unsuccessful one.

    2011/11/8 Olivier

    From another unsuccessful try, I got the following (anonymized) output:
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Calling Number (len=13) [
    Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
    (E.164/E.163) (1)
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: >
    Presentation: Presentation allowed of network provided number (3)
    ‘95135XXXX’ ]
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > [70 0b 80 30 36 37 31 30 XX
    XX XX XX XX]
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Called Number (len=13) [
    Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
    ‘06710XXXXX’ ]
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > [74 0e 21 01 8f 33 33 33 34
    34 33 XX XX XX XX XX]
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Redirecting Number (len=16)
    [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
    (E.164/E.163) (1)
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c:
    permitted, user number passed network screening (1)
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c:
    (15)
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: ‘333443XXXXX’ ]
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > [a1]
    [Dec 3 09:21:32] VERBOSE[6201] chan_dahdi.c: > Sending Complete (len= 1)

    1. Am I correct not seeing any meaningful difference with the successful
    one above ?

    From this, I would conclude by:
    A. either, there is a bug in libpri/dahdi as though pri debug shows 2 calls
    are treated the same (ie 2 different calls print the same output), in fact
    there is still a difference between them and this difference, in this
    specific case, change the way the CallerID is presented (for that I’ve got
    an pri intensive debug record at hand).
    B. either, the network behaves inconsistently : with the same input from
    Asterisk, it will either show or not show the CallerID though this data is
    passed to him.

    2. As I’m not using latest libpri and dahdi versions, my plan is to update
    to 1.4.12 and 2.5.0.2 without changing my asterisk 1.6.1.18 version and try
    again.
    Any comment on that particular mix ?

    3. I don’t believe much in alternative A.
    What do you think ?
    Suggestions are welcome.

    Regards

  • I don’t see any meaningful differences with what you have shown.

    I agree that the network appears to be handling the calls inconsitently.

    I don’t see any problems with upgrading those components.

    Libpri 1.4.12 is backward compatible with earlier versions. The API
    changes are for feature additions and not for changes in existing
    behavior.

    You should consider upgrading to Asterisk v1.8 so you can take advantage
    of the many ISDN supplementary services implemented since v1.6.1.

    Richard