spa3102 & CID

[kabelnet2]

Hi,

I have configured my SPA3102 to handle CID on PSTN line. In our country the standard is ETSI FSK + V23. Everything is working fine - during a few calls or on first day. After that the 'Private caller' string is displayed on the phone, no caller id displayed on WEB information screen. If I switch off and on the device (SPA3102), the CID is displayed again during a few calls.

I use the latest firmware (5.1.10).

I hope, someone can help me.

Regards, kabelnet (Tamás Borlay)

[kabelnet2]

Hi,

An important message is missing from this thread (why?). It was sent by Patrick Born on 30/10/2009:

Message:
--------------------------------------------------------------
Hi Tamás & Community,

Due to Sarbanes-Oxley rules, Cisco is not allowed to provide firm dates or set expectations about future features/bug fixes.

The SPA3102 CID issue is receiving Engineering attention and test code *may* be available by late December 2009. This timing is *my impression only* and is in no way a guarantee of what may or will happen.

Regards,


Patrick
-----------

[carlosevzz]

any update?

[dutchadept]

Hi,

Having similar problems with CID based on DTMFdetection (On-Hook) I've found out the following:

Having the same intermittend results regarding CID I started logging all events and analyzing the actual PSTN line. It seems the SPA has a very low tolerance regarding tone frequencies and voltages. These are greatly influenced by termination resistence and cabeling used.

Sadly, all answers I've received (from various sources) regarding this problem have been something like: change your ring -thru time.. tip/ring voltage adjust and similar non-related things for on-hook, pre-ring detection.

In my case, the SPA plainly misses a DTMF "D" signal every so often. This means that eventhough CID detection has been initiated (in this case triggered by a polarity reversal, but before the first ring) it only detects the actual phonenumber and the closing "C" DTMF signals. This can only mean two things:

1) The line impedance is completely off. This will kill DTMF detection since ETSI requires these tones to be > 37mV. This can be adjusted by the user through the proper termination impedance setting (and eventhough there is a "standard" for each country, sometimes you have to actually use a higher or lower value due to your cabeling, equipment and distance to the PSTN exchange).

You can check for this by logging your call state: if your DTMF detection is random, or consistently missing certain numbers/characters then there is a good chance that you have to change your terminating impedance. Since I only lose the first DTMF tone, this can be dismissed in my case.

2) The detection window is off. ETSI standards expect at least a 40ms signal per digit in the CID phase of the call. If somehow the FXO line on the SPA is not initiated yet, it can miss part of the tone, and therefore dismisses it as line noise. Now I suspect that that is the problem in my case, since I only miss the first DTMF character in the transmission: the crucial "D" which signals the start of de CID block. My line analysis showed the "D" properly coming in on the PSTN line, having the right frequency, voltage and duration. The same principle applies to FSK detection.

This can not be fixed by the user, it's a hardware/firmware related problem. Since the detection problem seems to start after a while and seems to be triggerd by a specific condition, I suspect that somehow the CID detection loop timings of the SPA are responsible.

Of course: ring voltage / time and ring thru time can be of influence for proper caller id detection (for the "after 1st ring" type like Bellcore) but if the statuspage shows ringing on the PSTN line, and logging shows at least the last digits of the originating phonenumber (yet not conform standards so ignored) then this is not the cause of CID detection problems. In my opinion, upping the tolerance for FSK/DTMF a bit and making sure that the SPA is immediately ready for detection after a polarity reversal (or first ring) will improve detection a lot.

Regards,

Alex

P.s. changing the CID regional values has no influence on the PSTN line detection, it's only to define how CID will be presented to all devices on the FXS line.

I confirmed this by offering the FXO port randomly FSK and DTMF CID and the SPA switched autonomously.

[bipin]

hi,

its so good to read such posts which actually help in understanding the functions of the device, just wish the linksys or cisco ppl would do the same on this forum.

i had one question though, UAE uses FSK type 2 caller id and like u said the device is made to detect caller id without depending on the caller id standard settings under regional, now in my case, the device just doesnt detect any FSK type caller id at all so i used a FSK to DTMF converter and then it started detecting DTMF but the reason i cant use that is then my device wont answer the call if the converter is in line for some reason.

what i also noticed is the device is slow in detecting the ringing, i mean once the first ring comes, then as soon as its about to end then status page shows ringing and my caller id is transmitted between first and 2nd ring so it might be true that the caller id detection loop timing is a bit messed up so which causes it to miss few digits in DTMF which takes a bit to be transmitted and misses FSK completely which is transmitted much faster.

when can we ever expect a firmware to fix this bcoz this is the only reason many ppl like me r shifting to other devcies which atleast do the job properly.

Regards,

Bipin

[dutchadept]

Hi Bipin,

What type of converter are you using (I assume an Artech based device like the EX700) and how is it configured?

And could you elaborate on: ", i mean once the first ring comes, then as soon as its about to end then status page shows ringing and my caller id is transmitted between first and 2nd ring....".

Have you made a detailed log of the FXO line during an incoming call yet (using slogsvr.exe)?

As for FSK detection: Here you are very dependend on the proper detection of the incoming ring signal and the quality of your local infrastrucure (=cabeling etc.). The "FSK after ring"  protocol  announces a CID payload (TAS alert) through a special ring pattern. If that pattern is malformed or too weak/strong it wil not get recognized as a TAS alert and the SPA will process it as a normal ring without CID data following.

The pre-ring FSK protocol has two possible signals for CID data annoncements. Either it is dual-tone or ringing pulse alert (DT-AS/RP-AS). Since the first depends on frequency detection and the second on ring detection, they both have their own possible solutions if CID fails.

FSK is nothing more then a 1200 baud modulated signal, so you could try to estalblish a good old analog modem connection using your PSTN line. If that fails, then infrastructure quality could be the issue.

Having said that, a lot of problems with FSK arise from detecting the channel seizure phase (after TAS or DT-AS/RP-AS). The exchange sends a 300 bit long message of alternating low/high (0/1) bits after which the SPA should synchronize transmission using the marker send right after. If any data is missing (not detected) from the channel seizure phase, then the marker doesn't get recognized and all FSK data is lost. If the latter is the case we have to wait for Cisco to fix the firmware.

It's also vital to know it your telco uses a polarity reversal prior to sending the first ring and if on/off hook signalling is used in the process.

So as you can see, a lot of things can be responsible for failing CID generation. Having a detailed log might help me getting an idea about your specific problem, but since the log does not show hardware/transport layer debug messages, there is only so much what I can deduct from analyzing it.

Be aware that some DTMF/FSK converter units only add to the incoming signal, so the SPA would be confronted with both FSK and DTMF. This would obviously confuse the system and give unpredictable results (especially if both pre and post ring data is presented to the SPA).

Regards,

Alex

[bipin]

Hi Alex,

im using the converter hown on this page

http://www.mycomsolutions.com/ex200/ex200.htm

its configured to send caller id in DTMF to the spa coz it wont respond if it receives in FSK and then u set it to convert to FSK.

Yes i have used slogsvr and i use that only for debugging the actual events in the spa, what i meant was the caller id is sent between the first and second ring and what i feel is the line rings first and when the first ring is about to end, then the entry in the log is generated regarding the ring detection, basically the entry to be registered is a bit slow.

yes i have tried conencting the same line to my 3com analogue modem and it detects caller id on everytime the phone rings without a single failure and i tried looking for softwares which could actually tell the exact message or type of caller id standard detected by the modem as lack of any analysis tools.

a siemens gigaset and a lg nortel landline phone detects caller id perfectly on the same line without a single failure so i doubt there r any issues with the cabling or line.

the spa was also tested using -ve line voltage as well as +ve by simply crimping the wires other way round.

i have tried putting the spa in all impedance combinations but i have never seen a single instance when the spa was able to detect caller id.

i have read almost any and every forum regarding help related to the caller id in the past 2 years or more.

Regards,

Bipin

[dutchadept]

Hi Bipin,

Yes, the device is an Artech unit, basically the same as I use in my setup (EX700 is actually an EX200 and EX600 combined). As I recall the EX200 only does FSK bellcore standard, and the successor (EX230) has ETSI/Bellcore select properties.

As for you testing if the signal actually is arriving through the line... I figured that you would have tested that to begin with (sounds like you get confronted a lot with help like "is the plug in the socket"... very fustrating isn't it?)

In your case the problem might be:

a) As stated before, the timing could be way off.

b) Off/On hook signalling from the PSTN exchange, now this one is tricky: I noticed that in some configurations the line get a off/on hook signal from the exchange. Most equipment ignores this signal if configured for Bellcore operation. The SPA however does not and generates multiple CID strings, one containing the number and one marked private/no CID.

If you can get hold of a EX700 unit (usually about $ 20,-) you normally can cure the latter problem: Changing the FSK signal to pre-ring (ETSI FSK) usually does the trick (this is the "fast" setting on the EX700 dipswitches). The unit is also able to disconnect the SPA from the PSTN line (while maintaining an operating current to fool the SPA) and intercept CID info. After receiving the data it actually generates a new CID to the SPA and then connects the PSTN line to the FXO port.

Again, having a look into your log would maybe give me more of an idea of your particular problem.

Regards,

Alex

[bipin]

sorry about that caller id converter model, actually its EX710 and the spa log as well as the converter pic is attached.

[dutchadept]

O.k., that logfile was not exacly informative so if you could please supply the following info:

Exact settings of your EX710:

Line/Int

Fast/Slow

DTMF/FSK

JT/Bellcore

(obviously, res/nor is set to normal...)

Then please generate the following logs, using "slogsrv.exe -t":

1) Call from a PSTN/Mobile number to your SPA (so no SIP to PSTN) WITHOUT the EX710

2) Call from a PSTN/Mobile number to your SPA with the EX710 connected between the wall outlet and the SPA

I assume the SPA is normally connected behind the EX710 and the EX710 is connected straight to the wall outlet. No line splitting/sharing.

Alex

[bipin]

firstly my EX710 has only 2 buttons, one for DTMF/FSK and second one for ETSI/US and my line is sending in FSK so leaving it to DTMF only gets the caller id converted, the ETSI/US doesnt make much of a difference and bytheway im trying to get rid of the EX710 thats y trying to make the spa detect caller id directly.

the log level is attached below, not much of a differnce. It is switched to full in the spa as well as the debug level to 3 but doesnt show much info

[dutchadept]

I understand you want to get CID working without the unit, but since you have been experiencing difficulties, lets see if the SPA reports CID at all..

As for the EX710: If you unscrew the two screws on the bottom and open the casing, you should see a dipswitch block on the PCB. I would like to know the current position of the jumpers.

The logfile you included in the last post, was it with or without the EX710 connected in between wallsocket and SPA?

(I asked you for a call log from both with and without the EX710 connected to the SPA.)

And could you include your current SPA settings.

[bipin]

the log i sent was without the ex710 and i opened the converter and there is no jumpers or dipswitches, image attached below.

alos attached is the log with the ex710 in line with it set to DTMF and ETSI.

the spa settings also attached

[dutchadept]

In regards to the EX710, I cannot find the user manual, but you must be able to set more values than just the two you mentioned. Especially INT/LINE and SLOW/FAST are important.

As for your logfile: with this "ETSI DTMF" setting the CID detection part of the process works just right (not saying that it has the desired result). Your log shows the SPA received "D" , "0559XXXX" and "C" and the ">>FXO:CNDD Name= Phone=055XXXX" confirms the SPA detecting and processing it correctly.

I take it that this log snipped is of one single incoming call, right?

If so, then the EX710 is not configured correctly: It does a pre-ring, polarity reversal DTMF CID generation (which obviously works for the SPA) but is also configured to INT setting (it keeps the SPA disconnected from the line, so after receiving the CID information the SPA gets disconnected and reconnected on every ring. This is messing up the CID process).

If you have the manual for the EX710, please find how you can set the device to LINE instead of INT, and see if you get proper CID info.

This should also fix the problem of the SPA not reacting to an incoming call.

If the PSTN ring thru LINE1 option is enable, do you get a number on your phone's display?

FSK alerting on your PSTN line must either be  DT-AS or RP-AS (since no Pol.Rev. signal was received from your telco) . If your impedance is configured correctly and your ring voltage, frequency and wave are also matching your telco's then there is really nothing more you can do to fix the FSK CID detection (assuming you've tested with both types of FSK modulation).

[bipin]

my ex710 doesnt have those features as i know the newer revision has those options so basically there is nothing much that can be done other than use those 2 switches, DTMF/FSK and ETSI/US, the revised version has that fast and slow setting.

the log is of a single incoming call

the messed up thing about the ex710 is that my telco does a pre ring without polarity reversal so when the ex710 detects caller id, it disconnects the spa from the line, receives the caller id from telco, then connect the spa back to line and transmit the converted caller id.

the settings of impedance etc r all based on what i read from many other forums and seem to work well for DTMF, call disconnection, ring detection etc so i assume there r perfect as the telco doesnt provide any such details of the line etc.

i guess im just done with this spa coz the cisco ppl seem least interested as no fix was ever posted and the product seems end of life so its doubtful anything will be fixed so im moving over to these devices which r much cheaper and atleast caller id workd perfectly.

http://www.hanlongtek.com/pro_list_3.html

[dutchadept]

Well, it's up to you.

The EX710 should have the LINE/INT option (http://www.artech.com.tw/showdetail.php?id=127〈=EN) and I'm 95% sure this will fix your problem. You can even try to find the EX700 (it would the cheapest solution)

As for Cisco and supporting this device: I have a feeling they're not too interested in developing many firmware updates for this model anymore. And quite frankly from a business point of view I can understand:

This is a Linksys/Sipura developed device, and even though it was aimed at small businesses it is primarily used by private individuals. Cisco has it's own line of VOIP solutions (firmly established within the business market) and with economic decline, demanding shareholders and limited resources due to accelerated growth in the last 10 years, they most likely focus their support effords on their native Cisco brand products.

Futhermore, Cisco is known for giving limited support to consumers.

This is also understandable to a degree because (my personal expierence) most problems reported by this group are either RTFM based, or they buy equipment without the proper education/training to operate it.

If you want full support for their devices you'll have to buy a support contract.

Having said all this, you and I actually have a valid problem/bug and Cisco did acknowledge this in this thread. They should stick to their promise and fix the CID routines in the SPA.

Good luck,

Alex