GSM's CLI is not transferring to SPA-3102 thru a 'GSM Fixed Wireless Terminal' whereas PSTN Line's CLI is properly visible

[Pradeep Hapuarachchi]

Hi Howard/Dan et al

Related to the same discussion under the “SPA 3102 - 'PSTN to VOIP' Call not establishing on CLI/CID enabled Telephone Line” couple of days/weeks ago. That is the reason why I am addressing to these 2 gentleman here. If anyone else also in a position to involve, its also very much appreciated.

This is an illustrated question around the same “Location A”. As I reported & you may remember all works fine. On top of that I am even able to see the Caller ID (CLI) from “Location B” which coming from PSTN of “Location A” . This is really a good.

However my setup is NOT simple as earlier explained. Because I have a GSM FWT (Fixed Wireless Terminal” hooked to SPA-3102 as per the attached manual diagram (Manual Diagram FWT setup.PDF). This is for the purpose of LCR (Least Cost routing) benefit,

When I getting a Call @ "Location A" to the PSTN Line connected, I can properly see the CLI from ‘Location B’. But if I get a call to a GSM SIM in the FWT, I do not get the actual CLI of the GSM call. Instead I can see the SIP number configured for the PSTN port (Line Port) of the SPA-3102. The FWT I got it from www.maxcomm.com.tw. And the Model is ‘TECOM MT-9966’ this device is supported CLI, DTMF, VOIP as per the provider/vendor Maxcomm.

Is there anything that I need to check from SPA point of view? Please advise. Would you think a SysLog output require for this ?

Kind Regds

Pradeep H

[Pradeep Hapuarachchi]

Yes totally agreed & really appreciated :)..

I am wondering how you respond this fast.

Not really sure which time zone you guys are in? (if you don't mind, I am not sure whether I am suppose to raise these type of questions )

[Dan Lukes]

Simple - email notification of new comment. And +0200 timezone.

[Pradeep Hapuarachchi]

Hi Both

Just a very interesting finding. Though I was not properly highlighted this earlier.

Today also I tested my MT-9966 by fixing a Panasonic display phone. Surprised to see when I call the GSM number in the FWT using an external PSTN line I can see the number thru CLI, But if I use another GSM mobile to call the GSM number in the MT-9966 FWT it is NOT showing the CLI.

Not sure how to provide the trace-log as it is Just a local connection between FWT and Display phone. Till I start doing the other proposed suggestion this information is just for some other thoughts.

[Dan Lukes]

CLI may not be available all the times. Either caller or callrer's operator may not provide them at all. Or a intermediate network may not carry such kind of information. Or it may be claimed private, so it's not delivered to called device. Or terminating operator may decide not to provide such kind of information to customer (either for free or at all).

In short - it may be either MT-9966 issue or network condition issue. Remove SIM card from MT-6699 and insert it into a casual mobile phone. Repeat the test calls. If the results will be same, then it's network condition and you have little chance to do anything with it. If the results will differ then it's MT-9966 issue - unfortunately, you have little chance to do anything with it.

[Pradeep Hapuarachchi]

Hi Dan

Yes the Test GSM numbers are belongs to me and I am 100% that those 2 operators are having CLI work. Yes wen the SIMs are in the normal mobiles I get CLI without fail for each and every call. In this case it was not intermittent, meaning NO CLI for all the test calls I made. Looks like my FWT is not passing the CLI for incoming GSM calls quite funnily. Remaining thing is I need switch all 3 CLI modes and see at lease if any one giving the CLI for GSM calls.

Another doubt, NOT sure Panasonic phone also has different behavior between GSM CLI and PSTN CLI.

Let me see that one as well..

[Dan Lukes · Accepted solution]

Well, if you are pretty sure the GSM provide CLI, then you verified that CNDD generated by MT-6699 is different that the CNDD passed thru MT-6699 from PSTN.

But the next device, either Panasonic or SPA3102 don't know the source of call, so CNDD generated by MT-6699 needs to be compatible enough with PSTN kind of signal - and both those signals needs to be compatible enough with receiving device.

Well. Do you know what flavor of CNDD signal is used on PSTN in question ?

[Pradeep Hapuarachchi]

Hi Dan, Howard

I am/was quite busy with few other things and still couldn't find a slot for more testing. Also my local provider has NOT provided the CLI/CID facility to my full time PSTN connected to the VOIP and FWT.

However I recently escalated the CLI issue to Taiwan based Vendor. He also still awaiting inputs from the PCB module manufacturer to see why CLI is NOT shown as its supposed to.

Till the PCB manufacturer provides/find out the problem, TECOM (FWT) vendor provided the following details. NOT sure you would be in a position to comment on the tech. specs. till then ?

SLIC of MT-9966

Power voltage: 48-56VDC

Loop current: 25mA

Ring voltage: >45Vrms, 20Hz

Metering pulse generator 12KHz/16KHz

Polarity reversal

V23/Bell 202 FSK Generator (CID)

DTMF decoder / enc

Bell 202A : Link type : Simplex Modulation: Phase coherent frequency shift keying. 8 Logical 1 : 1200+-12 Hz Logical 0 : 2200+-12 Hz Transmission rate : 1200 bits per second. Data : Serial, Binary, Asynchronous. Transmission level : -13.5+-1 dBm into 900 ohm. 

V.23 : Link type : Simplex Modulation : FSK Logical 1 : 1300+-1.5% Logical 0 : 2100+-1.5% Transmission rate : 1200 baud +-1% Received signal level for mark : -8 dBV to –40 dBV Received signal level for space : The received signal levels may differ by up to 6 dB for mark and space. Unwanted signals : Total power of extraneous signals in the voice band 300~3400Hz are at least 20dB below the signal levels. Data format : Serial binary asynchronous ( 1 start bit first, then 8 data bits with least significant bit first , followed by 1 stop bit minimum , up to 10 stop bits maximum). Start bit = 0 , stop bit = 1. 

[Dan Lukes]

Hm ...

Those data looks good, although they doesn't describe the SLIC operation mode in full. There are still open question related to exact timing and so on.

On the other side, even if FWT will provide full details, we don't know full specification of SLIC used in SPA3102. So we will be unable do decide who's guilty.

And even if we found enough data to decide who's guilty, it will not help us to patch neither MT-9966 nor SPA3102 to become compatible ...

Also, the particular pieces of either SPA3102 or MT-9966 you have may be slightly of the specification - as result of something broken inside (broken capacitor or so). Even broken device may still work well with some devices while other may not recognize it. It depend on tolerance of other device.

So you may have luck with other piece of either SPA3102 or MT-9966. Or not, of course ...

If I was in your shoes, then ...

... osciloscope may help me to decide the signal from MT-9966 looks distorted disclosing the MT-9966 is broken (either as a piece or as a product)

...  replacing of either SPA3102 or MT-9966 may help - SPA122 may replace SPA3102, I'm unsure about goot replacement for MT-9966. Note it may not help and such kind of hardware debugging is somewhat costly.

There's little I can advice you now. I'm out of ideas, sorry.

I'm considered to use other approach in my installations - I considered SIP to be "main" protocol, thus I'm converting all other sources into SIP (e.g. I'm using GSM<->SIP gateway instead of GSM<->POTS adapter, for example). It save me from all those POTS issues most of time.

Well, even if this thread will not help you, it may help to someone else. Consider rating of valuable advices ...

[Pradeep Hapuarachchi]

H Dan

Thanks for the comments and I will still follow up with the vendor for more inputs if any. Also as you say I doubt whether any minor malfunction happened due to frequent lightning in my home country where there is very poor earthing systems for electricity supply as well as telephony supply over cables. Because I have observed slightly different behavior of the FWT compared to my original usage period and initial testing.

Also I am thinking of GSM<->SIP gateway as well. what is the best model for a SoHO kind of an setup ??

However as of now, the worry here is FWT itself (alone) is NOT generating the CLI well . That is the most painful part. Also I have another FWT which is "Maxcomm FCT-335P".This also not 100% good as it was partially burnt due to a mild Lightning strike. Let me try that as well.

When it comes to rating, YES indeed this is a very good thread for me as well as for anyone else whom looking for similar references. How to Rate ? Do I need to say coreect answer ? OR any other way of rate this rather than saying Correct Answer. I can say that but it will NOT 100% reprsent the actual situation. Please comment...

[Dan Lukes]

Also I am thinking of GSM<->SIP gateway as well. what is the best model for a SoHO kind of an setup ??

I'm unsure I can give you valuable advice. It's little or no reason to arrange own GSM<->SIP gateway my country. It's better to arrange direct SIP trunk to mobile operator. But even it is not necesary most of time here. I can call mobile numbers at almost same price via a SIP operator, so no reason to arange dirrect connection to GSM.

But if necessary I like the BeroNet VoIP gateway because of their modularity. You may consider it costly for your installation ...

I'm administrator of rather middle or large installations than the small ones. Those few small installations, including my home one, use SIP trunk only. So sorry, I have little experience in SOHO kind of gateways ...

it was partially burnt due to a mild Lightning strike

You should use lightning protection on your's phone lines. As well as on power lines ...

How to Rate ? Do I need to say coreect answer ? OR any other way of rate this rather than saying Correct Answer. I can say that but it will NOT 100% reprsent the actual situation.

Don't use "correct answer" unless you feel it correct answer (but you may select more comments if they form correct answer together or any of them is correct answer alone).

There are small stars  in left bottom corner of other's comment. Just push n-th star to assign rating of n. It's common practice not to rate all comments, only the most valuable one only - e.g. those comments the other reader should not miss reading the particular thread.

Despite default "no rating" mean zero stars and it's most worse rating the comment may have, the "just one star" is mostly used to express "it's not true/crap/useless" comment - although technically one star is better than zero. So common practice is use either four or five stars to rate useful comments a ignore other comments unless they are upset you enough to be eligible for one star rating ;-)

Note you can't change you mind once rating has been assigned to particular comment.

Don't rate other comments just to make them happy. Rated comments should be valuable to others at the first.

[Dan Lukes]

Just for completeness (it will not help to solve this particular case, but may help to understand the matter) ...

Caller ID transfer method is not standardized well. There are so many methods used worldwide. Short and very simplified explanation for anyone interested ...

Before CND transmission the phone needs to be notified such transmission will begin. Following methods are used to alert receiving circuits:

1. Ring: casual ring. In such case data are transmitted between first and second ring.
2. DT-AS: Two tones of known frequency are used as mark.
3. RP-AS: Short ring pulse (few thousands of miliseconds)
4. polarity reversal: polarity of line reversed
5. OSI: Open Switch Interval - voltage is removed from line for a fraction of second

Sometime combinations are used - for example polarity reversal followed by either DT-AS or RP-AS; polarity reversal may or may not be preceded/followed by OSI and so on.

Sometime confirmation from phone's side is required. Short pulse of current drawing from line is one of known method of clear-to-send signal.

Well, now the phone know the transmission will occur. Following methods are most common for the data transfer:

1. FSK/Bell
2. FSK/.v23
3. DTMF

Sometime the data are transmitted with polarity reversal active (e.g. polarity is reversed before transmission and reverted back to idle state on end).

Data, once transmitted, needs to be interpreted. SDMF or MDMF format of data are most common with FSK. DTMF may vary in the terms of start & stop digit (DTMF-A or DTMF-D are most common start signals, DTMF-C is mostly used as stop digit, but particular network may use other DTMF signals to mark start & end).

To make things worse, different timings is used in networks - minimum / maximum length of particular signals (either TAS or particular DTMF digit) as well as minimum / maximum length of silences (from polarity reversal to DT-AS/RP-AS, from TAS to start of data transmission, DTMF interdigit pause and so on), loudness of signals used, acceptable voltage levels as well as current drawing ..., ..., ...

So interoperability issues are imminent.

Unfortunately, details are often not documented for particular device. In our case MT-9966 claim to generate FSK/v.23 style of CLID. Well, but what kind of TAS is generated before them ? Even ETSI EN 300-691-1 define four to be "standard".  What format of data is used at presentation layer ? We don't know. May be timing or the loudness of signals generated by MT-9966 is either so high or so low for SPA3102.

You claimed obvious idea ...

There must be a reason the SPA3102 does not decode the incoming data

... sure it is. I wish I described almost countless list of reasons why SPA3102 may not decode the incoming data properly ;-)

If you are curious, read ATA186 using CallerID Method DTMF and sending after first Call  - the ATA186 offer more detailed  configuration of CNDD;  despite of it, the user is asking how to handle method not covered by documented combination of options.

I'm not sure how to discover the reason

There's simple answer to such question - voltmeter, ring-detector, oscilloscope (with FFT support if possible). Unfortunately, it will not help to Pradeep. We may discover why it doesn't work, but we have no way to solve the issue in most cases (if the issue is caused by so loud signals we may insert the attenuator but it's almost only case we can do something) ...

 -----

I have SPA112 here and Gigaset E450 connected to them. Despite I'm not changing the configuration. The CLID is displayed on the phone for few days then become broken. No powercycle of neither SPA112 nor the phone will help. I change some random line parameters on SPA112 and CLID become working again. For few days. Then it stop again. Despite I know the theory of CNDD transmission in deep, despite I have voltmeter (but no oscilloscope), despite I can read SPA112 logs, despite I'm playing with it for more than year (occasionally, not daily) - it's still unreliable ...

"Why it doesn't work" is just wrong question. You need to have big luck - or carefully selected devices (both sides) to got it working.

[Pradeep Hapuarachchi]

Done the test as per....

Test 1 : Pass - YES I managed to see the external call CID thru FWT connected Display Analogue phone.

Test 2 : Under DTMF mode @ FWT

Fail - I did NOT see the external call CID in the SPA3102 connected Phone. Instead it shows the SIP Number only.

See attached SPA3102 - info page images during & after the call.

Also Tracelog attached - RingThruLine 1 = YES & PSTN Answer delay 16s. (TraceLog RingThruLine 1 with delay 16s.TXT)

[Pradeep Hapuarachchi]

Also I tested same way as above with other 2 types of CLI

( FSK Bell 202 mode )   
( FSK V23 mode )

See results attached.

One thing to Notice.. Please see '( FSK V23 mode ) 2.TXT' trace. I can not 100% understand. Looks like when the external Call comes from a GSM number to the GSM SIM in the FWT, CLI is NOT picks up even if I let it ring till long. Do you see it here in other Traces ? Quite Funny I guess..

[Pradeep Hapuarachchi]

Hi Dan / Howard..

I have some latest updates on the same subject. Would you recommend me to post them here or Open a new thread?...

[Dan Lukes]

Unless you changed the equipment to different one (so it's brand new issue with brand new hardware) then I wish it's better to continue here.