Bell Atlantic Mobile stopped displaying Caller ID
Doug Reuben
After about 6 months of nearly seamless Caller ID delivery on my Bell
Atlantic Digital Choice phone, Caller ID outside my local area all of a
sudden stopped working. Additionally, Alpha Messaging delivery STILL does
not work in most areas of New York City with BAMS/CT accounts although
tests with other BAMS accounts indicate that the service is indeed
available and working!
I have an BAMS/CT A-side digital account in the 860-604 exchange, which,
either as a result of my inquiries with BAMS and/or their own work on
their system, started displaying Caller ID when outside the CT/00119
system in mid-September 1997. This included nearly EVERY BAMS market; I
can't think of an area which did not ultimately receive caller ID,
although some took longer than others (most notably the South Jersey 0008
system which showed "Unavailable" months after the rest of the
00008/Philly system had it working.)
On or about April 3rd, at about the same time that BAMS proudly announced
in their New England market newsletter that Caller ID delivery is
available outside the CT system, it stopped working (great timing!). It
currently does not work anywhere outside of the 00119/CT market, and doesn't
even work in the Pittsfield, MA section of the 00119 market in the
Berkshires. Whenever a call from a phone which was _known_ to show the ID
(ie, calling number) in the past is placed to my 860-604 number, all I get
is "Unavailable". However, as a comparison, A BAMS-Philly 00008 215-287
exchange mobile that the company has ID's _perfectly_ in each of the
markets, including the non-BAMS SNET/00088 B-side market in CT and
Western Mass.
Specifically, the markets where I tested the CT/A and Philly/B mobiles
and found that the CT got "Unavailable" while the Philly always got the
calling number are:
00008: Philly
00018: Baltimore/DC (ID for CT DOES work via the DC roam port, however)
00022: New York Metro (ID works via roam port too)
00028: Boston
00078: Albany
00088: SNET - CT/A won't work at all there of course, but Philly gets CID!
00119: In CT/Springfield section, CID showed on both the CT 860 account and
the Philly account; but in Pittsfield system the CT 860 doesn't get
the ID and I have not properly tested the Philly act.)
00250: Atlantic City (incidentally, our Philly account was mis-billed as
non-home for calls made here; it is part of the expanded home area)
00300: Vermont
00404: Orange County, NY
00486: Poughkeepsie, NY
02058: NY-17 between 404/486 and Binghampton systems, up to Albany.
Again, it _used_ to ID fine in all of these markets, and the Philly
account currently does, so I can't see why they can't get it working
after over 5 weeks of outage and after publicly announcing it in their
newsletter!
Also, another long standing issue: CT/A accounts with Text Messaging
still can not get alpha messages in Queens, Kings (Brooklyn), or Richmond
(Staten Island) counties of New York/Boroughs of New York City. If an
alpha message is sent to you while you are in any of these counties, it
will not be received on the phone. However, the minute you cross into
Manhattan or the Bronx via any bridge or tunnel (BAMS covers all tunnels
in NYC now; AT&T still doesn't cover the East River tunnels), all your
messages come in in a flood which essentially locks up the phone until
you clear them out and/or they stop coming in.
BAMS maintained that this was due to the software in the switch covering
these counties, and that alpha messaging would not be available until the
switch was upgraded. However, after testing messaging out with the Philly
account, it surprisingly worked fine in all three counties! I therefore
suspect that it is NOT the switch which requires upgrading, but some
routing problem between the CT/A and NY/B markets, although this is only
speculation. The point, however, is that if it can work for a Philly
account, I fail to see why it will not work for a CT account as well.
I spoke to BAMS-CT customer service and roaming departments a number of
times over the past few weeks in efforts to resolve these issues, and they
forwarded forwarded my inquiries on to (supposedly) the appropriate
people), but still no progress. Indeed, the person who is looking into it
for me from the BAMS CT roaming dept. (Michelle) called today to ask me if
anything was working yet; I unfortunately had to answer "no" (I'm not
blaming her; she is just passing the issue on...)
It seems as if I am going to have to escalate the issue on my own now,
something which I don't have as much time to do as I used to. Towards this
end, I have compiled a list of systems (mainly BAMS at this point, but the
list will grow to include any and all other systems that I know about or
which people write in about) which I will post as soon as I have updated
it, probably in the next few days. In the meantime, a preliminary version,
as well as other cellular notes and observations, is available at:
This is a site where I hope to maintain a list of all known problems,
features, services, notes, etc. which I (and others who have written/may
write to me) have observed. If anyone is having similar problems, I urge
you to check this list, compare your observations to mine and those who
have written in, and provide any feedback which you may consider
appropriate. Hopefully, such a list will facilitate more rapid
resolutions to some of these ongoing issues.
Finally, on a positive note, the Catskill 01516 system which BAMS partly
owns has _finally_ been fully integrated into the BAMS system in that
automatic call delivery and custom-calling features work, etc. After many
calls and the exceptional help from Mark at the BAMS/CT roaming dept.,
BAMS finally got this market fully connected so BAMS customers may now
receive calls, use features (3-way calling is oddly implemented there,
though...see the notes at wirelessnotes.org for details), and place calls
without using the roaming operator. I'm glad they were responsive and
interested in resolving this issue -- it had been going on for a long time
and it is finally fixed.
I'll post an updated "Cellular Notes" list in the next few days, and
update the WWW site in terms of CT Caller ID and Alpha Messaging in the
New York counties noted above.
Please feel free to visit "www.wirelessnotes.org" and submit comments,
updates, new issues, observations, or anything else you think appropriate...
Thanks!
Doug
Doug Reuben / Interpage(TM) Network Services Inc. / www.interpage.net
dre...@NOSPAMinterpage.net
+1 (510) 254 - 0133
HDQ(203) 966 - 7000
FAX(718) 793 - 6081
Doug Reuben
In article <358a5a3c....@news.mindspring.com>,
S.C. <roamer1@-removeme-pobox.com> wrote:
(quoting my original post:)
>>After about 6 months of nearly seamless Caller ID delivery on my Bell
>>Atlantic Digital Choice phone, Caller ID outside my local area all of a
>>sudden stopped working. Additionally, Alpha Messaging delivery STILL does
>CID almost never works when roaming out of the Atlanta area with
>BellSouth. (Some areas -- including most other BellSouth areas,
>including Chattanooga which is home airtime but on another switch --
>don't even try to show CID at all, others show "NO ID CALL" (meaning
>that the switch didn't get CID from the Atlanta switch or a roamer
>port), and a very few small carriers show full CID.)
In an odd case, SNET/CT and Western Mass (B/00088), does display caller
ID for BAMS-B customers who roam into SNET's territory. This is one of
the few cases where a carrier not associated directly with a given "home"
carrier passes the caller ID on the mobile unit.
> Features (call
>waiting, etc.) are inconsistent, too. BellSouth has shown no interest
>in getting CID or the features to work, simply telling customers that
>"they don't work when roaming." :( At least they're being honest
>(well, not really - call waiting, three-way, etc. DO work, but they
>are inconsistent.)
Absolutely; feature code standardization or integration is a joke; it is
no wonder customers do not use it -- carriers have never shown any
interest in either standardizing feature codes or allowing your home
feature codes to work while roaming (some systems have different feature
codes from others; at the very least the feature codes you are used to in
your home market should work for you while roaming, ie the visited switch
doesn't have to interperet the code, just pass it along to the home
switch, or some analog to that.)
>Needless to say, B-side roaming is still nowhere near as seamless as
>with the A-side/NACN (I even still have to occasionally dial *18 in
>known auto call delivery areas.) -- the MFJ, which B-side carriers
>often thrown up by carriers when one complains about features when
>roaming, shouldn't matter anymore! :(
It doesn't; almost immediately after it no longer applied (and after
subsequent Justice Dept. rules were lifted, most previously restrained B
carriers started doing redirects while roaming (ie, unanswered calls go
to VM or No Answer Transfer).
The one complaint I have about the NACN is that a lot of ATTWS properties
(which as McCaw started the NACN) started using non-standard codes for
features, such as ATTWS/NY (00025) using *71 for Immediate Call
Forwarding (everyone else uses that for NAT, and ATTWS/NY doesn't even
offer No Answer Transfer which a user can set up and remove at will!).
There are a lot of systems which do not translate these properly while
roaming, meaning ATTWS/NY customers do not have access to a significant
feature while roaming. (Now ATTWS says "Well, most people don't use that
anyhow", but my point is that it is so complicated and lacks any sort of
standardization with other cellular services and even landline (where *72
or 72# is used for call forwarding) that it is no wonder so few customers
use it. )
>>system in mid-September 1997. This included nearly EVERY BAMS market; I
>
>BAMS markets _only_?
Generally, yes. Other than SNET's 00088 market, I don't know of any other
markets where Caller ID shows for BAMS customers who are
roaming...(unfortunately :( )
Anyone know of some other markets which DO show ID for BAMS customers?
Regards,
(This post and updated SID list are also available at www.wirelessnotes.org)
Regards,
Doug
Doug Reuben / Interpage(TM) Network Services Inc. / www.interpage.net
ds...@NOSPAMinterpage.net
Jeffrey Rhodes
Doug Reuben wrote:
snipped some, I'll return later to address some of the excellent roaming
issues raised.
> Absolutely; feature code standardization or integration is a joke; it is
> no wonder customers do not use it -- carriers have never shown any
> interest in either standardizing feature codes or allowing your home
> feature codes to work while roaming (some systems have different feature
> codes from others; at the very least the feature codes you are used to in
> your home market should work for you while roaming, ie the visited switch
> doesn't have to interperet the code, just pass it along to the home
> switch, or some analog to that.)
You must mean wireless carriers other than AT&T Wireless, right?
You obviously do not understand that IS-41 works exactly as you want.
The feature codes are not per-switch, they are per-home. When an AT&T
Wireless roamer dials *71 to invoke immediate call forwarding, the
visited switch wraps up all the sent digits and sends them back to an
AT&T HLR. It does not matter that the roamed to switch supports *72 for
the same thing for non-roamers.
It sounds like your experience is mostly with B-side carriers. A-side
carriers have been depending on the NACN's US national SS7 network to
help distribute roamer's home profiles for nearly 7 years now. The NACN
has performed an incredible job, B-side carriers and Iridium use it,
too, as well as other countries like New Zealand. It isn't easy
coordinating all the routing changes needed to support switch splits,
area code splits, new international countries, feature code triggers,
etc.
I'll respond to your most interesting posting's other details later. I
just wanted to plug how good the NACN really is, and you all can thank
AT&T Wireless (actually McCaw Cellular) for its inception.
Regards, Jeffrey
Jeffrey Rhodes
Doug Reuben wrote:
>
> In article <358a5a3c....@news.mindspring.com>,
> S.C. <roamer1@-removeme-pobox.com> wrote:
>
> >CID almost never works when roaming out of the Atlanta area with
> >BellSouth. (Some areas -- including most other BellSouth areas,
> >including Chattanooga which is home airtime but on another switch --
> >don't even try to show CID at all, others show "NO ID CALL" (meaning
> >that the switch didn't get CID from the Atlanta switch or a roamer
> >port), and a very few small carriers show full CID.)
>
> In an odd case, SNET/CT and Western Mass (B/00088), does display caller
> ID for BAMS-B customers who roam into SNET's territory. This is one of
> the few cases where a carrier not associated directly with a given "home"
> carrier passes the caller ID on the mobile unit.
This is an indication that the visited IS-41 system does not know how to
*get* or does not *want* the visitor's Caller ID-specific service
profile indicators, so the visited system automatically overwrites
whatever values are received, if any. AT&T Digital One-Rate service will
occasionally run into this kind of RF, which I believe is less than 20%
of North America. Remote Call Forwarding will still work, but otherwise,
the Digital One-Rate service will ALWAYS provide universal US Caller ID
functionality, in about 80% of North American RFed areas, just like at
home ;-) That's noteworthy, I think.
So it goes without saying too often, use *67 prefix dialing to send your
wireless digits to the switch, if you really want your outgoing call to
display 'PRIVATE' or "NOID'. For the primitive areas that don't
recognise the US *67 blocking prefix, your wireless number will probably
remain unseen for a display as "OUTOFAREA". Most states require *82
unblocking prefix wireless dialing, for unblocking the display,
regardless of the default values assigned in the visited profile.
> The one complaint I have about the NACN is that a lot of ATTWS properties
> (which as McCaw started the NACN) started using non-standard codes for
> features, such as ATTWS/NY (00025) using *71 for Immediate Call
> Forwarding (everyone else uses that for NAT, and ATTWS/NY doesn't even
> offer No Answer Transfer which a user can set up and remove at will!).
> There are a lot of systems which do not translate these properly while
> roaming, meaning ATTWS/NY customers do not have access to a significant
> feature while roaming. (Now ATTWS says "Well, most people don't use that
> anyhow", but my point is that it is so complicated and lacks any sort of
> standardization with other cellular services and even landline (where *72
> or 72# is used for call forwarding) that it is no wonder so few customers
> use it. )
Gee, GTE-NW ISDN makes me use #53,#54,#55 and #56 for busy,na transfer
and the ZyXEL P100 router's POTS port won't pass the # in a KEYPAD
message, so how well are these numbers standardized anyway? I like
NACN's approach for the seven series of feature activation dialable
triggers: *71 turns on immediate call forwarding which is the highest
precedence with respect to incoming calls, *72 is conditional call
forwarding, etc, and *FC0 (star digit digit zero) turns off the feature
at the Home Location Register. That means calls are diverted at the home
switch, not at the visited switch, for billing purposes, and we don't
have to remember something silly like "if the feature code is even, it
is on, if the feature code is odd, it is off."
Please don't ask me to explain all the types of call forwarding
diversion. There is immediate, conditional, busy, no answer, inactive,
default and unauthorized, at least. Not all of these are within a user's
reach and some markets, notably NY, have their own ideas about such
matters. Don't get me started, I want to believe that *71 SEND will
invoke the last immediate call forwarding number that I've registered,
so I don't have to keep entering the same number to toggle on and off
between home ring and cellphone ring ;-)
Just for the record, call delivery is NOT call forwarding and requires
separate "II" digits, pronounced as "aye-aye" digits, for Feature Group
D MF call setup. ISUP call setup uses "OLI" parameter, aka OLIP,
pronounced as "oh-lip".
> Anyone know of some other markets which DO show ID for BAMS customers?
I would think BAMS is part of NACN, so that any US Lucent Autoplex
switch will provide a visited profile that includes the user's home
Caller ID preferences, unless that visited state or that visited carrier
have default overrides in place.
Regards, Jeffrey