Voice problems

[dskobeev]

Good day!
Linksys PAP2T device. The voice disappears after 5 minutes of conversation. The call dump shows that Linksys sends an invite at the 300th second - can this be connected? How to disable the send of an Invite request during a call?

[Dan Lukes]

There are multiple reasons to send (re-)INVITE. But no re-invite should cause disconnection of audio stream. So I suspect the issue cause is different. I suspect NAT issue here.

Please turn on syslog&debug and capture messages. Also capture SIP and RTP packets related to particular (failing) call. It may help us to identify true cause.

[dskobeev]

Link to dump - https://www.dropbox.com/s/gpc3p797cy85mly/c7415a2c-826d873e%40172.25.150.48.pcap?dl=0

[Dan Lukes]

You either didn't enabled syslog&debug or you didn't configured tcpdump to capture them together with SIP&RTP.

The second invite fired at T+301.93 requests one-way audio:

INVITE sip:577......0@93.??.??.90:5060 SIP/2.0
...
Call-ID: c7415a2c-826d873e@172.??.??.48
CSeq: 102 INVITE
...
Expires: 30
User-Agent: Linksys/PAP2T-3.1.15(LS)
....
c=IN IP4 0.0.0.0
...
a=sendonly

The MERA softswitch honors such request.

But with no debug messages I have no idea why PAP2T is switching to 'sendonly' mode.

You are running somewhat ancient firmware (3.1.15), we are running 5.1.6 instead and it works. So it's either configuration issue or firmware bug. I hope the syslog&debug message (configure highest level possible and capture both of them) will disclose the cause.

[dskobeev]

Good day!

Included syslog and debug (3 + H).

According to the results I will write down
Thank!

[dskobeev]

Good day!

Link to SysLog - https://www.dropbox.com/s/gdy5j9rqk99ra3c/2018-12-27.csv?dl=0

Link to .pcap dump - https://www.dropbox.com/s/0hi3o2y9lihupw2/789a8d7e-b4df7511%40172.25.150.48.pcap?dl=0

Time to call - 11:41 +3 GMT

[Dan Lukes]

Packet dump you disclosed is from call not affected by issue. I'm hearing both sides from start to end with no problem. For the purpose of the analysis I need dump and log related to the affected call.

By the way, in the log you provided I see suspicious activity. Between some calls I see no off-hook/on-hook event I see hook flash instead. It may be intentional, but it may be also unintentional so fast click on the cradle hook switch.

In one case the call has not been disconnected at all, hook flash forced it on hold instead and second call has been originated at the same time. Is it intentional ? I'm asking because it may be related to the issue. Moreover, call on hold (not disconnected because of so fast on/off-hook considered hook flash instead) may be charged by your operator. So be careful.

To make analyses of your issue as easy as possible, disclose packet dump and log from isolated call affected by the issue. Call shall start and end in on-hook state (handset on cradle). Please make sure there's no second call on hold.

[dskobeev]

Another telephone can be connected to the gateway?

[dskobeev]

Challenge for 16:46. At 418 seconds, linkys sent an invite again, after which one voice disappeared

Link to .pcap dump - https://www.dropbox.com/s/rl01h63clqavdua/linksys_418_sec.pcapng?dl=0

Link to syslog - https://www.dropbox.com/s/ni6qwj001gc7sco/syslog.csv?dl=0

[Dan Lukes]

Unfortunately, syslog file ends on 16:49 while "sendonly INVITE" packets has been fired on 16:52.

We still have no both packet dump and syslog&debug from call facing the issue.

Also, it's unfortunate the syslog file you disclosed lacks exact timestamp. It's hard to correlate particular syslog lines to dump packets - but it's relationship in time is important.

Despite of it, dump and syslog discloses something very suspicious. According syslog, the sequence of SIP packets is as follows:

1. > INVITE (101 INVITE)
2. > INVITE (101 INVITE)
3. > INVITE (101 INVITE)
4. < 100 Trying (101 INVITE)
5. < 180 Trying (101 INVITE)
6. < 200 OK (101 INVITE)
   
7. > ACK (101 ACK)
8. < 200 OK (101 INVITE)
   
9. > ACK (101 ACK)
10. < 200 OK (101 INVITE)
    
11. > ACK (101 ACK)
12. < 200 OK (101 INVITE)
13. > ACK (101 ACK)

According dump, the sequence of SIP packets is very different:

1. > INVITE (101 INVITE)
2. < 100 Trying (101 INVITE)
3. < 180 Trying (101 INVITE)
4. < 200 OK (101 INVITE)
5. > INVITE (101 INVITE)
6. < 200 OK (101 INVITE)
7. < 200 OK (101 INVITE)
8. > INVITE (101 INVITE)
9. < 200 OK (101 INVITE)
10. > ACK (101 ACK)
11. > ACK (101 ACK)
12. > ACK (101 ACK)
13. > ACK (101 ACK)

 Can you explain such (substantial) difference in order of packets ? It looks like packets from MERA softswitch to PAP2T are substantially delayed somewhere in-between point of capture and PAP2T itself. Whats the network topology between those two points ?

[dskobeev]

Perhaps in this file syslog more information on the same call - https://www.dropbox.com/s/gdy5j9rqk99ra3c/2018-12-27.csv?dl=0

[Dan Lukes]

Following lines of log are ultimate answer:

27.12.2018 16:53,Debug,185.17.39.1,[0]Hook Flash

PAP2T has detected hook flash event sent by analog phone connected to it. Transition to "sendonly" mode is the consequence of it. DTMF dialing of 2671707687 follows.

I mentioned already I identified suspicious manipulation - hook flash instead of true on-hook/off-hook in-between two calls. It looks I guessed true issue cause even without syslog few comments ago.

My question is imminent - is the hook-flash fired intentionally ? What's the intended purpose of such signal ?

What values you have configured for 

1. Hook Flash Tx Method
2. Signaling Hook Flash Event
3. Call Waiting Serv, Three Way Call Serv, Three Way Conf Serv
   

?