Looking for the FCC ‘chapter and verse’ rules regarding that little packet of data that is sent with every phone call. The one that has the originating caller, the originating number and the destination phone numbers current timestamp.
I can’t find it and I really want to know what the FCC legally requires when it comes to the timestamp specifically.
I would appreciate it if you could help my find the legal rules because I can’t find them.
Thanks.
I lurk, therefore I am.
Are you asking about the technical implementation details? I think the FCC handed that off to industry groups like the IETF, SIP forum, and ATIS…?
e.g. The SHAKEN standards doc section 5.3.3 says:
5.3.3 Use of the Full Form of PASSporT
IETF RFC 8224 [Ref 13] supports the use of both full and compact forms of the PASSporT in the Identity header.
The full form of the PASSporT shall be used to avoid any potential SIP network element interaction with headers,
in particular the Date header field, which could lead to large numbers of errors being generated (the “iat” value in
the payload that is protected by the signatures should be considered a more reliable indicator of PASSporT
freshness than any time value in the SIP Date header).
And RFC8224 has details on the date header and iat token: RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP)
Sorry if that’s not what you meant!
No, it doesn’t seem to be what I meant.
This is about what might still be called landline phone calls. In my case the phone that comes with my Xfinity/Comcast set up.
As I understand it and maybe I don’t, when a phone call is made a little data packet with name, phone number and originating timestamp is added. When the call reaches it’s destination it’s confirmed by the first ring of the phone. After that first ring the data packet with name, number and the destinations current timestamp is sent.
I believe this time stamp is up dated to match the destination at what I’ve heard called the local Head End. This would be the last place the call passes through before it ends up at it’s destination.
I didn’t read all of what you linked to but that seems to be related to cell phone calls and stuff.
Regarding the legal requirements, I think the answer is the Truth in Caller ID Act of 2009. That makes it illegal to send inaccurate Caller ID information “with the intent to defraud, cause harm, or wrongfully obtain anything of value”. I’m not clear if you’re also asking for technical details on how Caller ID works, but there is some information here.
As I understand it, technically, while that’s a “landline” phone (as opposed to a cellular phone), it’s not a traditional POTS (“plain old telephone system”) landline phone, like you would have originally gotten from AT&T, and which operates over dedicated phone lines coming into your house, and connecting your phone to the outside world.
A landline via your ISP, like Xfinity, is a VoIP (Voice Over Internet Protocol) phone, and the calls are being transmitted via your internet connection.
I imagine that a VoIP phone system may handle that information, and transmit it to the phone system, differently than a POTS phone system would.
Probably right and I’m no expert, but I think the final destinations timestamp sent with any call is supposed to be accurate. They do send a time with every call, I know that. I just assume it’s supposed to be accurate.
I was hoping there would be an FCC rule that confirms that.
It sounds like you are talking about the SS7 signal. All voice traffic, whether POTS, cellular, or VoIP uses SS7 signaling to route traffic. I’ve been spending the last three years updating my company’s SS7 network, so the primary (A) links are no longer using individual 56k connections between switches.
The SS7 signal basically says, “Hi! I’m telephone number X and I’m calling telephone number Y.” And in response, “Hi telephone number X. I’m telephone number Y. Let’s shake hands.”
Telephone numbers should be the only information being sent.
Caller ID information is looked up by the receiving switch, which would be connected to a caller ID provider. It is not sent with the call.
As for what the FCC regulations are, I leave that to the lawyers.
To expand on this slightly, this is why some calls show as city, state: the database dip to look up the name information failed (no info, timed out, etc.) so the local switch did its best.
What’s the problem you’re trying to solve? Knowing that might lead to enlightenment…
Sorry I haven’t updated this sooner. The problem is the timestamp I’m receiving with incoming calls will sometimes jump ahead 2 minutes. It seems to happen after some sort of update, or reboot or something no one at Xfinity can/will that name happens from time to time.
I have an inline device whose sole purpose is to read/decode this caller-id packet that is sent after the first (handshake) ring completes at my phone. That’s device is where I see the timestamp error. This device will operate as a clock the rest of the time, only changing it’s displayed time if the caller-id packet gives it a reason to display something different. So, the 2 minute error remains until the next time this update/reboot happens and it’ll jump ahead another 2 minutes after the inline device decodes the latest caller-id timestamp, making it 4 minutes fast.
Xfinity techs are all like, “Wut? Never heard of it. pshh.” And can’t or won’t fix shit.
After looking into it on my own I found such a thing as this:
"A time synchronization method. The method comprises: sending by an optical terminal (OLT), a synchronization message to an optical network unit (ONU); receiving a time delay request message forwarded by the ONU, the time delay request message carrying a first timestamp; and carrying the first timestamp in the first time delay request message and sending same to a base station, the time delay response message being used for indicating to the base station to adjust the local time thereof according to the first timestamp. Also disclosed at the same time are an OLT, an ONU and a time synchronization system.
Timestamp counters of the active and standby OLTs in an Ethernet passive optical network (EPON) backbone optical fiber protection system can be effectively synchronized, and the offline state of the optical network unit (ONU) caused by timestamp drift in handover can be avoided."
So, it appears to me that some kind of optical fiber time synchronization drift error that isn’t fixed because, well because, ‘Who cares? Not my problem. Change the date and time on your telephone handset, or something. I don’t care what you do. Not my problem.’
My gut feeling is that these time sychronisation messages aren’t the source of your problem. Synchronisation like that tends to occur in order to ensure that the network nodes have very exact local times - of the order of milliseconds if not tighter. Network protocols can get badly broken in the face of bad times. Systems will tend to have pretty accurate local clocks, so even drifting if they are not communicating and able to stay in sync an offset is unlikely to reach even a second or so.
Is the time jump exactly two minutes? Two minutes sounds a peculiar value. Systems don’t tend to talk in minutes of anything. Seconds, or more likely microseconds, is what I would expect. Maybe 128 seconds could be a glitch, but that is still a bit of a stretch. I would expect weird time offsets to be a power of two, and in microseconds - or even nanoseconds. Depends on how many bits they have. 128 seconds is very close to 2^{27} microseconds. Point is - two minutes is just plain odd.
I’m even wondering if there might be a simple flaw in your device’s reception of the timestamps causing a glitched time. The coding isn’t the most robust, and a bit of extra noise, or constrained bandwidth of just the right nature, could lead to curious behaviour.
These are sometimes the most infuriating faults, yet when you get to the bottom of them, there is a quite extraordinary level of satisfaction to be had. Take it from me - don’t discount anything. Sometimes the reason is bizarre, and yet perfectly reasonable.
Reminds me of stories from the early days of phone systems. (As well as I can remember the story.)
Back in the days of human based exchanges, there was one particular customer’s line that seemed to behave oddly - but only on nice sunny days. These days the line would go active and then hang up again with a period of about a second. Which puzzled the operators and then the technicians greatly. Until one sunny day a technician visited the customer’ house, and observed that the telephone was on a desk by window, in full sunlight. The customer’s cat was curled up in the sun, pressed right against the phone, and its breathing was gently lifting and dropping the handset in its cradle.
I like the cat story!
We had a line that would ring trip randomly. Tech came out and eventually figured out that the wire ran through a tree. The branches had worn the insulation off, and if it was windy and damp enough, it would ground momentarily. Rerouting the wire fixed it, of course. How did they fix the cat problem? 
For OP: the time is transmitted with the CallerID information. So I don’t think the ONT/OLT/ONU is at fault here: it’s wrong coming from the CO. It sounds like it persists until some unknown other event occurs, sometimes even multiplying (well, adding). Presumably the techs you’re talking to haven’t heard of it because they’re dealing with customer equipment, not the VoIP “CO”. Do you have neighbors with the same problem? If not, then it might be your inline device, as previous comment suggests. Do you have any handsets that don’t use the inline device? Can you borrow one? That would let you narrow it down.
This is vaguely reminiscent of a problem from 40 years ago, in the early(ish) days of cable boxes: the time on our cable box would jump an hour occasionally. Finally narrowed it down to use of another remote. OK, so the signal is confusing the cable box–except that “jump an hour” wasn’t a function the box supported, so it made no sense. Cable company was, of course, clueless. This was the same cable company that offered simulcast stereo audio on FM for their movie channel. Only I had an early digital receiver, and the signal’s frequency would drift enough that the receiver would lose it. No other station had that problem, so I was sure it wasn’t the receiver.
Thanks for the reply.
Try something for me will ya?: Here’s a sort of local phone number; probably uses the same head end as I do. (810) 987- 8100. It’s an automated recording hosted by a local attorneys office. Don’t be scared. All it is is the local weather forecast but it includes what it says is the atomic clocks current time. So I ask if you could sync up one of your devices clocks so you know exactly what time it really is and then call the above number. If you’re synced up with the atomic clock, then the number you call should be exactly the same. But it won’t be. This is no coincidental glitch. If you call it now it’ll be 4 minutes fast.
My devices displayed time currently is correct, but that’s because I bitched about it and showed them the exact text quoted above. Without any affirmation on their part of course, they asked me to monitor incoming phone calls and see which one is responsible for the next jump in time. That phone only gets calls from 4 or 5 numbers. So that advice was ignorant BS. It always does and only happens after some sort of update/reboot of whatever the F it is they’re doing up stream. Sometimes I can tell when these happen because I’ll have to reboot the modem to get everything working again after they do one. Last time it was no TV till I powered off/on the modem.
Bottom line is that the time stamp is in their hands. They can F it up or they can fix it.
The device is in series, cable modem > phone output > callerID display device > telephone. All the device does is read and display that packet of info, passes the call along to the phone and just acts like a clock the rest of the time. It’s probably 20 years old and works flawlessly. Always has.
“Do you have neighbors with the same problem?” See the above suggested time sync/ phone call experiment for an example of neighbors with the same problem. Try it and post back here.
“Do you have any handsets that don’t use the inline device?” They don’t use the device at all, couldn’t if they wanted to because the device offers nothing to the phone except the incoming phone call AS IS.
The phone I use, a base with a portable handset, has an option to enable setting the date and time on the handset or use the incoming timestamp included in every callerID packet. I can’t see the time on the handset unless it’s right in front of my face, so it’s set to use the CallerID info. The CallerID display unit I’ve been referring to is like a big digital clock when it’s not displaying who’s calling. The only time it even mistakenly ‘appears’ to fail is when it gets crap sent to it.
Yep, time is wrong on that number. So yeah, it’s the CO, not in your equipment: you can’t fix it. All you can do is try to find out who CAN fix it.
That 810 number is listed as being through 9323 MICHIGAN BELL TEL CO but we know that doesn’t have to be correct any more.
You might try the FCC–srsly, this is the kind of thing they’ve surely dealt with. Of course they may be closed these days.
Thanks for the responses.
Because it’s been a local law group around here for decades I’m sure it’s listed with Bell Tel Co because it likely was since their beginning and they never changed the number. However, I think the law group has switched up to an Xfinity/Comcast system as that is the single most prevalent provider around here. The time displayed by my callerID unit was wrong by 4 minutes before too which led me to believe this law providers number is now via Xfinity/Comcast also.
And the time before that by 16 minutes before I complained enough to get it fixed.
Why 2 minutes? My guess I’m thinking that’s exactly how long it takes for this particular type of whatever it is that they run from time to time takes start to finish.
Why ahead instead of behind? I not sure. I could only guess
bodangus, is this you: Time stamp attached to incoming calls is often wrong. | Xfinity Community Forum
seems familiar doesn’t it?