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

[Dan Lukes]

Lets allow me to verify I understood.

1. In the case of the call LocB->SPA112->via IP->SPA3102->MT9966->via PSTN->a called phone you see caller's (e.g. LocB) phone number on called phone
2. In the case of the call LocB->SPA112->via IP->SPA3102->MT9966->via GSM->a called mobile phone you see LocA PSTN number on called phone instead ?

Correct  ?

[Howard Wittenberg]

Pradeep,

What you are experiencing would happen if your gsm terminal did not provide the incoming caller id to the SPA3102.

You have the SPA3102 configured to send the PSTN Caller ID for the normal VoIP Caller ID on the bridged outgoing call.  If the SPA3102 does not decode an incoming caller ID from the incoming PSTN on the FXO port, the SPA3102 will fallback to the default and will use the normal caller ID on the bridged outgoing voip call.

A sip debug trace would show whether or not the SPA3102 received a caller id from your device or not.

Searching for a User Manual for your gsm terminal, I see you need to configure that device for the Caller ID Type to use,

Caller I.D. Type. 

This is to set the type of caller ID that phone(or PBX) may receive for a
MO incoming call.
1.) Pick up the handset and press: *#***8326#
2.) Dial tone
3.) Press*#51#Caller I.D. type#
4.) A confirming tone is heard
?Note?
0: disable
1: DTMF(default)
2*0: FSK Bell 202
2*1: FSK V23 

http://users.atw.hu/parts/telecom/mt9960.pdf

[Pradeep Hapuarachchi]

Hi Howard

understood what you are trying to explain.

Actually I have contact with the FWT vendor and he gave me the settings to check as below. As a default CLI is enabled in the FWT. Also I tried to switch the following Bellcore/ETSI FSK modes as well. But no Luck. May be I will do a Syslog debug soon and send you all.

He says the commands in the Manual is NOT 100% correct and following is the correct ones. (See specially for the last 2 Modes). Honestly I also having a bit of ambiguity by seeing the different codes whether which one is exactly right. Anyway let me see to setup a Debug trace.

 ( Turn Off CLI )

＊＃＊＊＊8326＃ 

＊＃51＃0＃              

 ( DTMF mode )

＊＃＊＊＊8326＃ 

＊＃51＃1＃              

( FSK Bell 202 mode )   

＊＃＊＊＊8326＃ 

＊＃51＃2＊＊0＃      

( FSK V23 mode )   

＊＃＊＊＊8326＃ 

＊＃51＃2＊＊1＃    

[Pradeep Hapuarachchi]

Hi Howard

While you refer the comment above about the FWTs some parameters (related to CLI)....

I am attaching the Trace-log Results.

As per the File 'To PSTN Line (CLI Works).txt' I am getting an external call @ LOC A which comes thru the PSTN line attached to FWT's Line Port. Under this scenario I am able to see LOC A's external call number (CLI).

As per the File 'To GSM Number (NO CLI Working).txt' I am getting an external call @ LOC A which comes thru the GSM number in the FWT via FWT's Line Port. Under this scenario I am NOT able to see LOC A's external call number (CLI).

Please let me know how would you see the behavior in the trace-logs.

[Dan Lukes]

The most important parts of both logs:

to_pstn_line_cli_works.txt:

Calling:17772327245@in.callcentric.com:0
FXO:CNDD Name= Phone=332287698
FXO:Stop CNDD                                      
FXO:CNDD name= number=332287698
Caller ID:       
--     Name             = (null)
--     Remote Number    = 332287698
--     Dialable Number  = (null)
--     No Number Reason = (null)
--     No Name Reason   = (null)
--     Message Waiting  = (null)
--     Date [truncated]
fxo cnddwrap_feed parse ok 332287698  status=2

to_gsm_number_no_cli_working.txt

CNDD_ST_SEEK_PREAMBLE error count=5      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=5      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=4      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=4      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=3      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=3      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=2      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=2      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=1      [1]    [1]
CNDD_ST_SEEK_PREAMBLE error count=1      [1]    [1]
FXO:Start CNDD

If I understand how the MT-9966 works, in the case of PSTN call it just pass-thru the signal as is, including the CNDD data. In the case of GSM call there's no CNDD in it, so it's generated by MT-9966 itself. Such (MT-9966 generated) signal is not recognized by SPA3102 then.

It's not so good. Well.

1) what CLI mode you had configured in the MT-9966 during this test ?

2) can you provide trace data for other two formats as well ?

[Pradeep Hapuarachchi]

The results above under ( FSK V23 mode ) of MT-9966

Let me get the Tracelogs under other 2 modes.

[Howard Wittenberg]

Pradeep,

I would run some basic tests to establish that your GSM provider is sending a usable CLI.

Test1:  Disconnect the cable from your MT-9966 to the SPA3102.  Attach the cable to an analog phone.  Call the GSM number.  Look for a display of the CLI on your analog phone.  This would show that your MT-9966 is passing CLI to an attached telephone. 

Test2:  Assuming Test1 shows a CLI with the cable connected to an analog phone.  Connect the cable back up to the SPA3102.  Temporarily change the settings on the SPA3102 PSTN Line Tab to "Ring Thru Line 1: Yes" and "PSTN Answer Delay: 16 (seconds)".  Call the GSM number.  Look for a display of the CLI on the analog phone attached to the SPA3102.  Restore the changed settings.  If this test works but the forwarding does not work then in the original settings the PSTN Answer Delay of 3 seconds is not long enough.  You would need to increase that setting until it works.

If neither test above work, then you need to devise a test to prove that the incoming GSM call is providing CLI to the MT-9966.

[Dan Lukes]

Note 1: MT-9966 needs to be configured to provide CLI in the format suitable for phone connected.

Note 2: DTMF/FSK Bell202/FSK v.32 are formats of data layer. If configured accordingly, the CLI data message will be delivered to called equipment. Unfortunately, such message itself will be encoded as either SDMF or MDMF message (two possible formats). We don't know what message format the MT-9966 is using to encode CLI, but if it use MDMF and analog phone will understand SDMF only then no CLI will be shown despite sent. Check phone's documentation if possible to become sure it support both message formats. If impossible to verify, use a recent model of analog phone (higher chance it will support both formats).

[Howard Wittenberg]

Pradeep,

The debug traces verify and documents that the SPA3102 does not decode incoming caller ids for any of the different box settings.  

With the DTMF CLI delivery setting, the trace shows a polarity reversal signalling the start of a caller id arrival but then nothing is received before the start of the internal signaling to send the call internally in the SPA3102 to the phone attached the Line 1 Tab.  Other delivery settings typically send the data between the first and 2d ring.

You raised question about the V23_mode_2 trace.  As you know you read the traces from bottom to top.  I don't see anything unusual with it except, of course, it does not receive an incoming caller id.  The bell_202_mode trace has a couple of calls on it, the first shows a polarity reversal before the call starting, but again nothing unusual.

The SPA3102 should support the different types of signalling.  I don't know what to suggest that wouldn't be just shooting in the dark.  There must be a reason the SPA3102 does not decode the incoming data, however I'm not sure how to discover the reason.

[Pradeep Hapuarachchi]

Hi Howard,

Thanks, let me do few more testing. All what I did with the help of my father at remote end. I am not living at the SPA3102 home I am in another country.

I have another plan as I requested CLI from the local telco to my other PSTN. Then it will be less wire handling to my father. I can do most of the things by myself.

Also FYI, I am using  following Trace programme (NOT Wire Shark). Do you think this programme (Syslog Watcher 4) is a good one ? See attached image.

[Howard Wittenberg]

Shooting in the dark,  you could try varying the PSTN to SPA Gain setting with some test calls.  This would change the volume of the analog call, but of course it would also affect the call talk volume and some settings could also introduce echo.  The Admin manual says:

dB of digital gain (or attenuation if negative) to be applied
to the signal sent from the PSTN side to the SPA. The range
is -15 to 12.
The default is 0.

The sip debug trace syslog will show some events in the adapter that are not shown by the external packets.  Your syslog capture program is fine.  My preference would be for one that read from top to bottom instead of the other way around. I would also prefer one that did a better job with the date/time stamp.  I like the simple program that you can download from Cisco.  You can get timestamps with it if you start the program with -t.
https://supportforums.cisco.com/document/36921/using-slogsrvexe-utility 

Wireshark is good, it will capture the syslog messages although it truncates the longer ones.  If Wireshark is also capturing the actual packets of the call WireShark has an outstanding call formatting feature and you can even capture and listen to the audio if you wish.

[Dan Lukes]

Note the local-loop from MT-9960 to SPA3102 is very short. I'm got better results (not only CNDD but also voice quality and modem/fax transmission) using -6 or even -9db with such kind of configuration in the past.

Wireshark is good, it will capture the syslog messages although it truncates the longer ones.

Wireshark is not quilty as far as I know. They are sent truncated.

[Pradeep Hapuarachchi]

Hi Both

Thanks for the inputs so far. Let me put them in to test soon.

Also tested the slogsrv.EXE which is simple and easy. Log file also looks smaller.

Let me use this as its records the chronological actions from the start to bottom.

Traceability point of view as Howard says its more logical and easy though I am not capable enough in analyzing tracelogs. Without 100% understanding how the electronic interfacing and working inside it is very hard to trace issues it seems.

Most of the things, once you explain I can understand but if I am trying to pick the issues by the Log it is practically impossible.

[Dan Lukes]

Without 100% understanding how the electronic interfacing and working inside it is very hard to trace issues it seems.

It's why I spend time to explain even some background in details.  ;-)