SIP2SIP

Reproducable: always
Environment:
pbxes.org uses outbound trunk: 100447036676@sip2sip.info
receiving account 2233513173@sip2sip.info
receiving client #1: Snom 370
receiving client #2: Groundwire 2.4.9
Both clients are in the same LAN behind a Peplink Balance 310 multi WAN router.

Each incoming call always ends after 30 seconds, due to a BYE message received from the Groundwire SIP client, due to not receiving an ACK from the proxy. This is the correct behaviour for the client in this situation. The problem is the lost ACK. It looks like the proxy.sipthor.net receives the ACK to deliver to 92.254.51.247:64446 (TLS) but it doesn't do it. We can't say why.

Trace for a bad call (to Groundwire): [[https://mdns.sipthor.net/sip_trace.phtml?cdr_source=sipthor&callid=dsPntBZo2.qwxxcbRVtG1ZDmg.zgnuma&fromtag=WUoCyIa6dZ6bYFMGCQ1ya3uwN.gBsOHv&totag=7C704D0577E2AAC079EB71E06B119B4F&proxyIP=85.17.186.7]]

An interesting thing is that the BYE is received from a different port than 64446 (64461).

Another trace for a bad call: [[https://mdns.sipthor.net/sip_trace.phtml?cdr_source=sipthor&callid=63a0d7780e9ea8ab606c2d4c63f4bcdf%4088.198.69.250&fromtag=as74d87ecf&totag=6674E2EE9099E4C5BA442D16E786FBE3&proxyIP=85.17.186.7]]

I see the ACK arriving at node7 in packet 22/31, but never leaving.

Trace for a good call (to Snom 370):
[[https://mdns.sipthor.net/sip_trace.phtml?cdr_source=sipthor&callid=22c140ce76e1d0ef06bc14bf24077b0d%4088.198.69.250&fromtag=as016aeec5&totag=5vjgow9h2l&proxyIP=85.17.186.7]]

Here I see the ACK arriving at node7 in packet 16/31, and immediately leaving to 92.254.51.247 in packet 17/31, this call is not disconnected after 30 seconds.