Solved: Frustrating, but here is

khavusr · ‎01-07-2015

Recently installed a SPA112 unit which so far works fine and without any bigger issues but have a few minor issues to solve. Among other I can't get the anwering machine to record incoming messages; when there is an incomming call which the answering machine picks up the call the caller gets busy line; meaning that the caller is not able to hear the outgoing message nor able to record?

To be mentioned that I before this was using a Thomson 78x vDSL modem which offered two pots which the same equitment that I'm using was connected to and which also the answering machine worked fine with. So nothng has changed with the setup expect that the SPA112 replaced the Thomson dsl modem when it comes to handle the voip part.

One of the suggestion that I've seen is to change the 'Reorder Delay' to 15 which so far hasn't made any difference.Also, the ring waveform is set to Sinusoid and the default voltage value.

Open for suggestion to point me in the correct direction what to look for in the config for the SPA112.

Dan Lukes · ‎01-08-2015

Text format in UCS-16 encoding and time with no seconds can be ignored. But messages are truncated at the first ',' and rest is missing. Second file is the SQLite database ..

You are testing my ability do identify and process obscured data, isn't it ?

Well, I decided to extract the lines from SQLite database as TXT form is incomplete. I know no format if Tm column, fortunately, we need no absolute time and I wish I guessed correct relative time in seconds.

So result (comments embedded):

Incomming call:

002.13 >>> CC_eventProc(), event: CC_EV_SIG_CALL_ARRIVED(0x31), lid: 0, par: 0, par2: 0x40956900
002.16 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_RINGING
002.16 ::: [0]CID:CID_initGen() >>> offhook 0 delay 1200 phone abcdefg786 name 46bcdefg786
002.23 ::: CID:OnHookTx PolRev

Caller ID transmission:

002.33 >>> uchSendDTMF(), sending DTMF 12 to line 0
002.33 ::: [0]CID Start DTMF/FSK, CID_ST_ACTIVE
002.48 >>> uchSendDTMF(), sending DTMF a to line 0
002.64 >>> uchSendDTMF(), sending DTMF b to line 0
002.80 >>> uchSendDTMF(), sending DTMF c to line 0
002.96 >>> uchSendDTMF(), sending DTMF d to line 0
003.13 >>> uchSendDTMF(), sending DTMF e to line 0
003.29 >>> uchSendDTMF(), sending DTMF f to line 0
003.45 >>> uchSendDTMF(), sending DTMF g to line 0
003.61 >>> uchSendDTMF(), sending DTMF 7 to line 0
003.77 >>> uchSendDTMF(), sending DTMF 8 to line 0
003.93 >>> uchSendDTMF(), sending DTMF 6 to line 0
004.08 >>> uchSendDTMF(), sending DTMF 14 to line 0
004.25 ::: [0]CID CID:DONE

Six rings:

004.52 ::: CID:Ring Now
004.54 >>> SLIC_startRing state 0 ts 0x1aa4ccon 1000 off 5000 len 60000
004.54 >>> [0]Ring cad event 0 pol 0
009.33 >>> [0]Ring cad event 0 pol 0
014.12 >>> [0]Ring cad event 0 pol 0
018.92 >>> [0]Ring cad event 0 pol 0
023.73 >>> [0]Ring cad event 0 pol 0
028.52 >>> [0]Ring cad event 0 pol 0

Off hook:

029.50 >>> [0]Off Hook
029.51 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_RINGING, new state CC_CST_ANSWERING

Call fully connected:

029.57 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_ANSWERING, new state CC_CST_CONNECTED

Disconnected from remote side:

039.62 >>> SIP_sessDlgEventProc: event: 45(SIP_EV_DLG_BYED), ucState: 3
039.62 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_CONNECTED, new state CC_CST_INVALID

CPC sent to called device:

047.64 >>> CPC SLIC_SET_OPEN_STATE on line 0
048.05 >>> CPC go to CC_CST_IDLE line 0
048.05 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_INVALID, new state CC_CST_IDLE

Called device still off hook, assuming new (outgoing) call:

048.07 >>> cepIdleProc(lid=0, call=0x17a974, event=9(CC_EV_USR_SEIZURE), par=0, par2=(nil))
048.07 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_DIALING

Called device on-hook, call cleanup:
048.72 >>> [0]On Hook
048.73 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_DIALING, new state CC_CST_IDLE

Device off hook, outgoing call starts, collecting dialed digits:

060.05 >>> [0]Off Hook
060.06 >>> cepIdleProc(lid=0, call=0x17a974, event=9(CC_EV_USR_SEIZURE), par=0, par2=(nil))
060.07 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_DIALING
065.20 >>> SIP_sessDlgEventProc: event: 41(SIP_EV_DLG_TERM), ucState: 4

Device on hook again, no digit has been received in this round:

066.01 >>> [0]On Hook
066.01 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_DIALING, new state CC_CST_IDLE

Device off hook, outgoing call starts, collecting dialed digits:

079.17 >>> [0]Off Hook
079.19 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_DIALING
081.68 >>> line:0 DTMFON event received digit a
081.81 >>> line:0 DTMFON event received digit b
081.94 >>> line:0 DTMFON event received digit c
082.07 >>> line:0 DTMFON event received digit d
082.20 >>> line:0 DTMFON event received digit e
082.36 >>> line:0 DTMFON event received digit f
082.49 >>> line:0 DTMFON event received digit g
082.62 >>> line:0 DTMFON event received digit 7
082.76 >>> line:0 DTMFON event received digit 8
082.89 >>> line:0 DTMFON event received digit 6
090.96 >>> cepDialingProc(), event = 33(CC_EV_TMR_DIALPLAN)

Digits are collected (dialing commited by dial plan timeout):

090.96 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_DIALING, new state CC_CST_CALLING
090.97 ::: Calling:abcdefg786@bahnhof-lda.soho1.voip.bahnhof.net:0, rc=0
091.47 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_CALLING, new state CC_CST_PROCEEDING

REGISTER procedure has been fired and completed during the call setup:

097.66 >>> [0]RegOK. NextReg in 296 (1)

Call fully connected:

099.05 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_PROCEEDING, new state CC_CST_CONNECTED

Disconnected from remote side:

103.75 >>> SIP_sessDlgEventProc: event: 45(SIP_EV_DLG_BYED), ucState: 3
103.76 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_CONNECTED, new state CC_CST_INVALID

CPC sent to calling device:

103.76 >>> CPC statr timer CC_EV_TMR_INVALID
111.76 >>> CPC SLIC_SET_OPEN_STATE on line 0
112.19 >>> CPC go to CC_CST_IDLE line 0
112.19 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_INVALID, new state CC_CST_IDLE

Device still off hook, assuming new (outgoing) call:

112.22 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_DIALING
Hook flash event occurred. Call 0 (collecting digits) cancelled. New call (1)
created, collecting digits:

112.37 >>> [0]Hook Flash
112.37 >>> CC_eventProc(), event: CC_EV_USR_HOOKFLASH(0x3), lid: 0, par: 0, par2: (nil)
112.37 >>> NEW_CALL_STATE(), call 0: old state = CC_CST_DIALING, new state CC_CST_IDLE
112.43 >>> NEW_CALL_STATE(), call 1: old state = CC_CST_IDLE, new state CC_CST_DIALING

No digit dialed, dialing timeout fired:

136.34 >>> NEW_CALL_STATE(), call 1: old state = CC_CST_DIALING, new state CC_CST_INVALID

Line is still of hook at the end of log.

Well. So we have commented log. Now - whats your question ?

Note that CPC Signal (Calling Party Control Signal) is a momentary drop in voltage (0 volts DC) on the line for a period of time. It's the way how the "server" side of analog line (SPA112 here) inform calling device (your machine here) that call has been disconnected by called side. Also, Cisco is using CPC to signal remote disconnection even it the case of incoming calls despite CPC has not been intended for such call direction.

Not every phone can recognize CPC signal, especially when called. SPA112 needs to be configured according capabilities of particular phone.

View solution in original post

Dan Lukes · ‎01-07-2015

You provided no information about timing.

Hypothesis 1:

caller machine waits so long and SPA112 cancels the call as so long unanswered

reconfigure you answering machine to pick-up call immediately. If it will not help, we can forged your issue is caused by timeout.

Hypothesis 2:

Answering machine analog line configuration is not compatible with analog line configuration of SPA112. So SPA112 doesn't understand machine signals and vice versa.

Voice -> Regional -> Miscellaneous parameters needs to be configured according answering machine requirements.

Hypothesis 3:

Issue is caused by something other. Turn on syslog&debug and catch them using remote syslog server or packet catcher. Catch SIP messages as well, if possible. It will help to analyze the issue.

Rate useful advices (or mark response as correct if applicable). It will help others to found solutions.

khavusr · ‎01-07-2015

Thanks for the input Dan and here is what I can provide so far on the two first hypothesis to try out; I'll get back tomorrow with the info for Hypothesis 3.

Hypothesis 1: Settings the answering machine to pick-up the call immediately gives me a busy line directly.

Hypothesis 2: the settings that I can think about which should tune the SPA112 to support the local Swedish analog lines would be 1) Ring 1 Cadence which is set to 60(1/5), 2) FXS Port Impedance which is set to 270+750||150nF and finally I've also set the Caller ID Method is set to DTMF (Finland, Sweden). Else from that nothing has been changed in the Misc section.

As said, I'll get back with additional info tomorrow.

Dan Lukes · ‎01-07-2015

I'll get back tomorrow with the info for Hypothesis 3.

You should. The POTS line signalization doesn't allow to reject call that has not been picked-up first.

khavusr · ‎01-08-2015

For Hypothesis 3 here is the syslog where I've set the SPA112 to capture debug data for kernel and system information and as well, to be on the safe side, I've attached the SPA112 own log as well; so let's hope that the necessary data has been generated. I've placed 1 call from the outside where ther anwering machine picks-up the call directly and 1 call with the machine picking-up the call after 30 seconds and finally I've made one call from the inside to an external number.

Update#1: When placing a call to my mobile, which works out fine, I did indicate from the mobile that I was busy by sending a text message back using the caller ID. Since this is a text sent to a land line, the telco calls the land line and uses an automatic voice to read the text message. This seems not to work out that well either; when answering the phone, everything goes silent and no message is given.

Dan Lukes · ‎01-08-2015

My fault.

I assume you configured it in Administration -> Log section only.

For the purpose of your isue we are more interested in log configured in Voice->System instead.

You need to configure both Syslog Server and Debug Server (to the same destination IP) . Set Debug Level to 3 and Syslog/Debug Transport to UDP.

This log will be more useful for us.

By the way, you didn't mentioned the firmware version you are using. So I assume you are using the latest.

khavusr · ‎01-08-2015

Here is the syslog set from Voice/System as well. Also, here is the sw/hw info for the unit:

Model: SPA112, 2 FXS
Hardware Version: 1.0.0
Boot Version: 1.3.1 (Dec 11 2013 - 11:38:47)
Firmware Version: 1.3.5 (004_XU001) Sep 16 2014
Recovery Firmware: 1.2.0 (001)

Dan Lukes · ‎01-08-2015

Lets go. At the first, records in your file is out of order. As a example, see sequence:

962->1043->1053->1052->1051->1050->1049->1048->1045->1046->1041

Unless you caused it by an post-processing of captured file or it's bug of the syslog server you used, there is something wrong with your network. Although IP messages may be reordered in transmit, it should be rather rare.

For the purpose of the analysis I ordered your log to be sequential. In advance I removed columns and rows that are not important for us. At the same time I obfuscated some information I wish you may not be happy to disclose. The result is attached bellow. You may consider to delete attachment (which still contain some sensitive informations) from your original message.

Call A:

13:05:10 [0928] CC_eventProc(), event: CC_EV_SIG_CALL_ARRIVED(0x31), lid: 0, par: 0, par2: 0x40956900
13:05:11 [0960] NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_RINGING
13:05:11 [0962] [0]CID:CID_initGen() >>> offhook 0 delay 1200 phone abcdefg786 name 46bcdefg786
13:05:12 [1022] CID:OnHookTx PolRev
13:05:12 [1024] uchSendDTMF(), sending DTMF 12 to line 0
13:05:12 [1026] [0]CID Start DTMF/FSK, CID_ST_ACTIVE
13:05:12 [1032] uchSendDTMF(), sending DTMF a to line 0
13:05:12 [1039] uchSendDTMF(), sending DTMF b to line 0
13:05:12 [1046] uchSendDTMF(), sending DTMF c to line 0
13:05:12 [1053] uchSendDTMF(), sending DTMF d to line 0
13:05:12 [1060] uchSendDTMF(), sending DTMF e to line 0
13:05:12 [1067] uchSendDTMF(), sending DTMF f to line 0
13:05:13 [1074] uchSendDTMF(), sending DTMF g to line 0
13:05:13 [1081] uchSendDTMF(), sending DTMF 7 to line 0
13:05:13 [1088] uchSendDTMF(), sending DTMF 8 to line 0
13:05:13 [1095] uchSendDTMF(), sending DTMF 6 to line 0
13:05:13 [1102] uchSendDTMF(), sending DTMF 14 to line 0
13:05:13 [1109] [0]CID CID:DONE
13:05:13 [1113] CID:Ring Now
13:05:14 [1118] [0]Off Hook
13:05:14 [1122] callEventProcTable[5] is cepRingingProc
13:05:14 [1124] NEW_CALL_STATE(), call 0: old state = CC_CST_RINGING, new state CC_CST_ANSWERING
13:05:42 [1148] [0]On Hook
13:05:42 [1159] NEW_CALL_STATE(), call 0: old state = CC_CST_ANSWERING, new state CC_CST_IDLE

Call B:

13:05:46 [1220] CC_eventProc(), event: CC_EV_SIG_CALL_ARRIVED(0x31), lid: 0, par: 0, par2: 0x40956900
13:05:46 [1248] NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_RINGING
13:05:46 [1250] [0]CID:CID_initGen() >>> offhook 0 delay 1200 phone abcdefg786 name 46bcdefg786
13:05:47 [1314] CID:OnHookTx PolRev
13:05:47 [1316] uchSendDTMF(), sending DTMF 12 to line 0
13:05:47 [1318] [0]CID Start DTMF/FSK, CID_ST_ACTIVE
13:05:48 [1324] uchSendDTMF(), sending DTMF a to line 0
13:05:48 [1331] uchSendDTMF(), sending DTMF b to line 0
13:05:48 [1338] uchSendDTMF(), sending DTMF c to line 0
13:05:48 [1346] uchSendDTMF(), sending DTMF d to line 0
13:05:48 [1353] uchSendDTMF(), sending DTMF e to line 0
13:05:48 [1360] uchSendDTMF(), sending DTMF f to line 0
13:05:48 [1367] uchSendDTMF(), sending DTMF g to line 0
13:05:48 [1374] uchSendDTMF(), sending DTMF 7 to line 0
13:05:48 [1381] uchSendDTMF(), sending DTMF 8 to line 0
13:05:49 [1388] uchSendDTMF(), sending DTMF 6 to line 0
13:05:49 [1395] uchSendDTMF(), sending DTMF 14 to line 0
13:05:49 [1396] _uchPlayDTMF(), Play digit 14 EP 2, ret=0
13:05:49 [1407] [0]CID CID:DONE
13:05:49 [1411] CID:Ring Now
13:05:49 [1416] [0]Off Hook
13:05:49 [1422] NEW_CALL_STATE(), call 0: old state = CC_CST_RINGING, new state CC_CST_ANSWERING
13:06:17 [1447] [0]On Hook
13:06:18 [1458] NEW_CALL_STATE(), call 0: old state = CC_CST_ANSWERING, new state CC_CST_IDLE

Call C:

13:11:05 [1766] CC_eventProc(), event: CC_EV_SIG_CALL_ARRIVED(0x31), lid: 0, par: 0, par2: 0x40956900
13:11:05 [1794] NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_RINGING
13:11:05 [1796] [0]CID:CID_initGen() >>> offhook 0 delay 1200 phone abcdefg304 name 46bcdefg304
13:11:06 [1860] CID:OnHookTx PolRev
13:11:06 [1864] uchSendDTMF(), sending DTMF 12 to line 0
13:11:06 [1866] [0]CID Start DTMF/FSK, CID_ST_ACTIVE
13:11:07 [1875] uchSendDTMF(), sending DTMF a to line 0
13:11:07 [1882] uchSendDTMF(), sending DTMF b to line 0
13:11:07 [1889] uchSendDTMF(), sending DTMF c to line 0
13:11:07 [1896] uchSendDTMF(), sending DTMF d to line 0
13:11:07 [1904] uchSendDTMF(), sending DTMF e to line 0
13:11:07 [1911] uchSendDTMF(), sending DTMF f to line 0
13:11:07 [1918] uchSendDTMF(), sending DTMF g to line 0
13:11:07 [1925] uchSendDTMF(), sending DTMF 3 to line 0
13:11:07 [1932] uchSendDTMF(), sending DTMF 0 to line 0
13:11:08 [1939] uchSendDTMF(), sending DTMF 4 to line 0
13:11:08 [1946] uchSendDTMF(), sending DTMF 14 to line 0
13:11:08 [1947] _uchPlayDTMF(), Play digit 14 EP 2, ret=0
13:11:08 [1953] [0]CID CID:DONE
13:11:08 [1957] CID:Ring Now
13:11:09 [1964] SIP_sessDlgEventProc: event: 45(SIP_EV_DLG_BYED), ucState: 0
13:11:10 [2003] NEW_CALL_STATE(), call 0: old state = CC_CST_RINGING, new state CC_CST_IDLE

Call D:

13:11:27 [2028] [0]Off Hook
13:11:27 [2038] cepIdleProc(), SYS_NOREG_CALL(0)=0, SIP_REGISTER_OK(0)=1
13:11:27 [2044] NEW_CALL_STATE(), call 0: old state = CC_CST_IDLE, new state CC_CST_DIALING
13:11:30 [2059] line:0 DTMFON event received digit a
13:11:30 [2094] line:0 DTMFON event received digit b
13:11:31 [2129] line:0 DTMFON event received digit c
13:11:31 [2165] line:0 DTMFON event received digit d
13:11:32 [2201] line:0 DTMFON event received digit e
13:11:33 [2237] line:0 DTMFON event received digit f
13:11:33 [2273] line:0 DTMFON event received digit g
13:11:34 [2315] line:0 DTMFON event received digit 7
13:11:34 [2351] line:0 DTMFON event received digit 8
13:11:35 [2387] line:0 DTMFON event received digit 6
13:11:41 [2431] cepDialingProc(), event = 33(CC_EV_TMR_DIALPLAN)
13:11:42 [2441] NEW_CALL_STATE(), call 0: old state = CC_CST_DIALING, new state CC_CST_CALLING
13:11:42 [2445] Calling:abcdefg786@bahn.....net:0, rc=0
13:11:43 [2534] Remote IP/port: X.Y.Z.103:9234
13:11:44 [2566] CNAME PPP00PQ3Q01@M.N.O.12
13:11:44 [2567] NAME "Kim Haverblad"
13:11:44 [2568] TOOL Cisco/SPA112-1.3.5(004_XU001)
13:11:44 [2578] NEW_CALL_STATE(), call 0: old state = CC_CST_CALLING, new state CC_CST_PROCEEDING
13:11:54 [2670] CC_eventProc(), event: CC_EV_SIG_CALL_FAILED(0x2A), lid: 0, par: 3, par2: 0x25
13:11:54 [2674] CC:Failed w/ Calling
13:11:54 [2675] NEW_CALL_STATE(), call 0: old state = CC_CST_PROCEEDING, new state CC_CST_INVALID
13:11:57 [2682] [0]On Hook
13:11:57 [2694] NEW_CALL_STATE(), call 0: old state = CC_CST_INVALID, new state CC_CST_IDLE

OK. Call A and Call B are very similar. Incoming call in OnHook state. Caller ID transmitted via DTMF, ring, someone picked up, so line is in off-hook state. So far so good. Call should proceed to CC_CST_CONNECTED state. And there is something wrong. Call doesn't move from CC_CST_ANSWERING. Called machine's patience become exhausted, so is going on-hook. Standard call cleanup follow.

Call C is also incoming call (but from other caller). This call has been cancelled by caller during ringing phase, before it has been picked by caller. There is nothing wrong with such call and we can forget it at all.

Call D is outgoing call. On-hook, digits are collected. Your dial plan is still not in good shape, you has to wait six second for dialplan timeout (message #2431). It's not bug, you just need to wait. OK, number is considered complete, so call request can be send to PBX. Call is entering CC_CST_PROGRESSING phase - it mean it wait a response from PBX. But there is no response at all. Timeout is firing, call is considered failed, standard call cleanup follows.

For more information about call state you can read Call states of SPA IP Phones and ATA devices (NewCallState syslog message)

Well, so we have log analysed. Now a conclusion. Despite I got no SIP capture, the case seems to be clear. SIP packets sent from SPA112 are not delivered to PBX while SIP packets from PBX are delivered to SPA112 with no problem. It explain why incoming calls never never CC-CST_CONNECTED state as well as why outgoing call remain in CC_CST_PROGRESS state.

On the other side, your phone is registered (message #2038) so two-way dialog has been successful in the past.

So it's network issue. Either firewall or NAT or so is not configured improperly on the path. It cause that some SIP packet from you doesn't reach the PBX.

If we will take out-of-order syslog packets into consideration, it may be major network issue as well - overloaded router, overloaded line, wrong router configuration, halfduplex/fullduplex ethernet issue ... It's not possible to decide now.

Well, and now some side notes.

1. It seems you have configured proxy using name bahn...soho1....net. I have no experience with such config on SPA112, but all SPA9xx, SPA3xx and SPA5xx are known to not to work well with with such kind of setup. You should consider using IP here instead of name.

2. PBX seems to offer you following codecs:

Rx payload list:
   PCMU/8000(0)
   PCMA/8000(8)
   G.729/8000(18)
   NSE/8000(100)
   encaprtp/8000(112)

It's rather suspicious for the PBX located in Sweden servicing clients in Sweden. uLaw (a.k.a. PCMU) is used in no Europe country, so offering them as most preferred codec is nonsense. aLaw (a.k.a. PCMA) is native uncompressed codec used in Europe so it should be most preferred uncompressed codec instead. It says something not so nice about professionalism of Bahnhof IP telephony provider. I recommend you to disable uLaw codec in SPA112 configuration. So it will not be used on outgoing calls and will not be accepted for incoming call. aLaw will be used then. Using uLaw may cause unnecessary transcoding on the path which may be source of sound distortion.

3. Despite this thread is dedicated to other issue and it is focused on Asterisk, it reveal issue that may affect you as well. I have this sentence in the mind:

When Asterisk resolves bahnhof-lda.soho1.voip.bahnhof.net it simply takes the first ip address and considers this the SIP peer. The problem is that a inbound SIP call can come from any of the six addresses and not only the address you registered at.

I'm not sure, but it seems it may apply to SPA112 as well. Call arriving from other IP that you are registered to will be rejected. Note it's not the same issue I mentioned in side note [1].

khavusr · ‎01-08-2015

Might be the syslog server issue/bug; so I've changed to another one syslog software which I hope works better moving forward.

And here are init feedback on the bullets;

1) Using IP instead of name entry doesn't work; so it's the same issue as described in bullet 3 with the naming and ip address for the SIP peer.

2) The preferred codec under Voice/Line1 was set to G711u which I changed to G711a - assuming that the U resp A stands for ulaw resp alaw for this codec.

3) In this case I just need to set the my fw to open up for IP's coming from this Bahnhof proxy which I can do in the fw config and as well taking a look again at the NAT rules that I have setup and add an address lists with the expected IP's and where to send the traffic.

I'll keep you posted & thanks so far for the feedback!

Dan Lukes · ‎01-08-2015

Unfortunately, you has not been so specific saying "doesn't work".

The [3] claim that INCOMING call will be refused if it will arrive from other IP that the proxy name has been resolved to.

The [1] claim that device will lost the ability to resolve IP address from proxy name, so device will REGISTER no longer. It will cause that no calls, either incoming nor outgoing, will be possible anymore regardless of the IP. This behavior is known to be deterministic on SPA[359]xx. I'm not sure it will apply to SPA112 as well.

So [1] and [3] are not the same.

khavusr · ‎01-08-2015

Sorry for being a bit vague here; but with saying "doesn't work" it's then ref to that using the IP address instead of the naming the domain/host didn't do the trick for the SPA112. I wasn't able to get any open line when trying. Changing back again from IP to domain/host; I was able to open the line and place call.

So I've tried to figure out as many of the IP's behind the proxy and added an address list to my firewall and assigned this list to the NAT lists which forwards the necessary ports to the SPA112. And that seems to done the trick. Now I'm able to make a call from my mobile and the answering machine picks-up the call after 30 seconds.

Briefly looking at the syslog I can see that it still make some query compliants. So for this syslog I've attached I've placed the following calls through the SPA112:

1st Call: Land line to mobile and hanging up without answering.

2nd Call: Land line to mobile and answering the call and handing up on the mobile phone.

3rd Call: Mobile to land line where the answering machine now picks up the call after 30 sec.

Let's see what you make out of the log this time; hopefully this ought to be close to be solved... I hope.

Also, regarding dial plan I'm still looking into this to ensure that I will have a well defined dial plan. Oddly it seems hard to find someone who would be able to share a well defined dial plan which works for Sweden... But, working on it and will share.

Dan Lukes · ‎01-08-2015

We should not try to fix what's not broken. So forget the name/ip format of proxy option issue that seems not to exists.

According attachment ...

... unfortunately, I'm not able to read XLSX format. I have no newest Office (nor Windows). Save it as CSV or so, please ...

khavusr · ‎01-08-2015

Here is the syslog as text file instead; hope it helps.

Dan Lukes · ‎01-08-2015

With many lines like the following one ...

08/01/2015 19:44,Info,192.168.0.12,#NAME?,,,,
08/01/2015 19:44,Info,192.168.0.12,#NAME?,,,,
08/01/2015 19:44,Info,192.168.0.12,#NAME?,,,,
08/01/2015 19:44,Info,192.168.0.12,#NAME?,,,,

... and others damaged other way unfortunately no ... ;-(

khavusr · ‎01-08-2015

Frustrating, but here is another try; the zip file has csv and syslog file. So I hope that either of them work out this time.

I did run two new test again; this time the 1st call was from mobile phone to the land line where the answering machine picked-up the call and played the outgoing message and where I'm able to leave a message as well. And the 2nd call was from the land line to the mobile phone and hanging up on the mobile.

issues with SPA112 and answering machine

Incomming call:

Call A:

Call B:

Call C:

Call D: