those are capture from 'Voice' syslog at level '3'. and also have system syslog and sip syslog enabled. i'm attaching the whole thing to this and also here:

https://gist.github.com/fd0e92daa5eafff514e4

after level '3' i have  '3+router' '3+comma' '1+comma'. i suppose router doesn't apply to me since there is no router on the ata (possibly some other device with the same firmware). but dunno what comma is. in any case please let me know if more verbose log is needed.

and in terms of file format; i have rsyslog daemon listening on a server and everything is captured into systemd's journald. if you need tcpdump i will have capture those on the ethernet port of the router that creates the nat for us. are those needed too?

It seems you has attached wrong files. They are still OS syslog, not those captured from Voice application.

SPA112 will not capture voice syslog for you - don't download catched syslog files from them. IP address of syslogd server needs to be configured for both syslog server and debug server on Voice tab so voice syslog messages are sent to such remote syslog server. I need recorded messages from such (remote) server then.

As alternative to remote syslog server you can use tcpdump to catch SIP and SYSLOG packets sent from SPA112. Resulting .pcap file needs to be renamed to pcap.txt (you will not be allowed to attach it here unless renamed).

Level 3  is enough.

See also Debug and syslog Messages from SPA1x2

Please attach files here, don't place them on third party store like github. You can attach multiple files to message.

"and debug server", i followed the link you just posted from Patrick and it says 'one or both' so i just used 'syslog server' and no the 'debug server'. anyway, i will try with *both*.

alright, i seem to have it now. lots of authentication info are included though... we're waiting for a call drop to trace... will report back here.

SIP use Digest style of authentication and even debug log contain no password. Despite of it, you may consider to change the password once case will be closed.

Note the debug log may contain information like calling&called numbers&names, IP adresses and others. Don't disclose capture file if you consider them so sensitive.

had one drop yesterday and yesterday was busy, wow. to be honest i would be happy with it's just one drop per day but going by experience it's not going to stay that way. in any case i'm attaching the log here.

it all happens at 18:44; so i'm just posting logs with that time stamp.

it's the firs call from _CALLER_07 that was dropped. duration on CID of my provider is 00:01 (1s). 2nd call starting at 37 (_CALLER_37) was fine.

in the mean time i asked my provider to run trace at their end for 24h. i will see if i can get a copy from them and post it here too later on today.

Lets analyze.

1. Call has arrived, RING signal has started on line 1 (SLIC_StartRing), CID has been sent (CID:DONE).
2. Line 1 handset has been picked up ([0]Off[276]: Hook)
3. New call state (connected) has been announced to peer and confirmed (SIP packet exchange before SIP_EV_DLG_CONNECTED)
4. Two way uLaw audio channel ready (from Rx only to bi-directional)

So far so good. And then we received following packet from service provider:

SIP/2.0
Via: SIP/2.0/UDP 72.55.168.18:5060;branch=z9hG4bK4ceb7354;rport
Max-Forwards: 70
From: "_CALLER_07" <sip:5140000007@72.55.168.18>;tag=as1611bada
To: <sip:192813_cr@172.16.1.18:5080>;tag=f30f2f1675887c86i0
Call-ID: 6289304e098c04bd7832a982023255e6@72.55.168.18:5060
CSeq: 103 BYE
User-Agent: voip.ms
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0

Such BYE claim "Normal Clearing, code 16" which mean "remote side just decided to hangup".

Well, it seems not to be true - but it's what you service provider has claimed.

Unfortunately, only service provider may disclose why he BYEd the call prematurely. It may be because he considered call over by self or because he just forwarded call clearing signal he has received from their upstream service provider.

Ask your service provider. No way to judge on your side who has initiated the channel clearing (and why). 

well, was there a *HANGUP* signal being sent from my side? i take it that you didn't see any HANGUP being sent from ATA and server just decides to BYE the connection, correct?

the 24h trace they started at my provider will end in about 3 hours from now, then they can give me a copy and i will post it here.

was there a *HANGUP* signal being sent from my side?

No, the BYE has arrived from your service provider.

 you didn't see any HANGUP being sent from ATA and server just decides to BYE the connection

You hit.

"You hit."?

It should be "You got it", sorry.

np, i was thinking "you hit the nail on the head" though.

this is what i got back from my SP:

"If the bye is being send from our end, it is hard to determine the actual reason because the X-Asterisk-Hangupcause is a standard resolution for a call closure, even in the situation that we can confirm this is being send from our end, there is no specific reason we can come up with as part of the trace reading.

However, we can verify for certain settings. Usually under normal circumstances the RTP timeout is participant of during the communication and if there is a long period where the RTP packets are not being send out in between the communication, a normal closure would be expected, but this replies and goes accordingly to your actual PBX configuration.

I will investigate further and be able to reply back on sunday, I will check along with my colleagues for this specific behavior."