This is a caller-id related issue as to how the OBI handles a "blocked", "anonymous" or "unknown" call and what information is passed to the sp1 or sp2 service.
The OBI should be using the information contained in the FSK signal to create the appropriate SIP messages so a "service" like Asterisk can handle the caller-id just like it would handle it from a VOIP trunk....
The OBI is not handling the "O" & "P" type calls correctly according to the specification. By making everything but numbers blank , as is currently the case, it is discarding important caller-id information that is used by all sorts of telephone devices.
What I'm suggesting is that the Obi either include or have an option to include the ascii "O" or "P" if it's in the FSK stream rather than ignore it.
Caller-id spec docs indicate:
"If the calling party's directory number is not available to the terminating central office, the phone number field contains an ASCII 'O'. If the calling party invokes the privacy capability (blocking), the phone number field contains an ASCII 'P'. "
Please read below:
Caller ID Format
The following 2 formats are used in the United States to send the CID information:
• SDMF - Single Data Message Format
• MDMF - Multiple Data Message Format
SDMF supports a single data type and is used to send the phone number for number only service.
MDMF supports multiple data types and is used to send name and number information. It is structured so that new types of data can be added easily (address?, city?, state?, etc).
Both formats include a value to determine the type of data to follow (data type word), a value to indicate the length of the data (data length word), and a checksum. See below for an example of each format.
SDMF Example
Here is an example of a SDMF message. Each byte is in HEX.
04 12 30 39 33 30 31 32 32 34 36 30 39 35 35 35 31 32 31 32 51
04 - message type word - 4 indicates SDMF 12 - 18 decimal, number of bytes in date, time and phone number 30,39 - 09, September (ASCII) 33,30 - 30, 30th day (ASCII) 31,32 - 12, 12 hour (ASCII) 32,34 - 24, 24 minutes (12:24 PM) (ASCII) 36,30,39 - 609, Area code (ASCII) 35,35,35 - 555, prefix (ASCII) 31,32,31,32 - 1212, sufix (ASCII) 51h = Checksum Word
Thus, the CID string can be summarized as follows:
The message is in SDMF format, consisting of 18 bytes of information, not including the checksum. The call was made on September 30 at 12:24pm. The calling party's phone number was (609)555-1212.
If the calling party's directory number is not available to the terminating central office, the phone number field contains an ASCII 'O'. If the calling party invokes the privacy capability (blocking), the phone number field contains an ASCII 'P'.
The following SDMF string is an example of a call that was blocked. The 50 just before the checksum is the ASCII code for a 'P'.
04 09 30 39 33 30 31 32 32 34 50 12
MDMF Example
Here is an example of a MDMF message. Each byte is in HEX.
80 20 01 08 30 33 32 34 30 39 30 32 07 08 4A 4F 48 4E 20 44 4F 45 02 0A 38 30 30 35 35 35 31 32 31 32 7D
• 80 - Message type word, 80 indicates MDMF
• 20 - Length of data, 32 bytes in date,time,name and number
• 01 - data type, 1 = date & time
• 08 - length of date and time, 8 bytes
• 30,33 - 03, March
• 32,34 - 24, 24th day
• 30,39 - 09, hour
• 30,32 - 02, minutes (9:02am)
• 07 - data type, 7 = name
• 08 - length of name, 8 bytes
• 4A - 'J'
• 4F - 'O'
• 48 - 'H'
• 4E - 'N'
• 20 - ' ' (space)
• 44 - 'D'
• 4F - 'O'
• 45 - 'E'
• 02 - data type, 2 = phone number
• 0A - length of phone number, 10 bytes
• 38 - 8
• 30 - 0
• 30 - 0
• 35 - 5
• 35 - 5
• 35 - 5
• 31 - 1
• 32 - 2
• 31 - 1
• 32 - 2
• 7D - Checksum
The following is a list of possible data types:
• 1 - date & time
• 2 - phone number
• 4 - number not present
• 7 - name
• 8 - name not present
If the calling party's directory number is not available to the terminating central office, the phone number and name fields contain an ASCII 'O'. If the calling party invokes the privacy capability (blocking), the phone number and name fields contain an ASCII 'P'.
From what I have seen, the types 4 and 8 are always followed by a length value of 1 and then either a 'P' or an 'O' to indicate unavailable or blocked, respectively.
________________________________________
Checksum
The checksum value contains the twos complement of the modulo 256 sum of the other words in the data message (i.e., message type, message length, and data words). The receiving equipment may calculate the modulo 256 sum of the received words and add this sum to the received checksum word. A result of zero generally indicates that the message was correctly received. Message retransmission is not supported.
