In the recent past I’ve observed some incoming SIP calls from outside without incoming audio and it turned out that my 200 OKs do not get answered with ACKs in these cases.
My settings allow early audio, so that explains why RTP packets are flowing to the other end. More than 99% of all the calls are not affected, and if so, the other side are always cellular phones.
Has someone observed something like this before? Could it be that these phones are merely temporarily in a dead spot ? It would be something like that they can trigger a call, but are then not able to answer properly.
This is a flow diagram of one of these calls (incoming leg). There’s no ACK after the initial 200 which leads to the repetitions. When the call gets terminated locally, the other side replies properly with a 200.
I am basically talking to my service provider, so anything behind that is almost a black box for me. As said before, this happens very rarely and it is hence difficult to get a SIP trace from Asterisk. Some of my systems are reporting to HOMER servers, so I can go a couple of days backwards if necessary
You didn’t say you were using TCP. I think the provider has to be broken, but I would like to see a 200 OK in its entirety, as i suppose it is just possible that the Contact header was telling it to do something silly.
Yes, the content of the 200 ok would be interesting. The destination IP seems to be Deutsche Telekom, correct? They are pretty picky about content - maybe there is a problem? But usually, if there’s anything wrong, they immediately drop the call completely. Strange.
But if you can see the problem only with cellphones, I wouldn’t investigate any time as cellphones usually are pretty unreliable in Germany (bad networks). The Response for the bye is probably generated by the SIP server itself, whereas the ACK comes from the cellphone?
Asterisk sets the proper values for external_media_address and external_signaling_address and again, the problem occurs very rarely, but I can identify the pattern with the missing ACK.
Meanwhile I can exclude a weak signal on the other end.
Then the question would be, why not all calls are affected.
On the other hand, calls may get treated differently depending on whatever. I just made sure that there is no extra stuff in the Server header, as some strings of my own git branches sneaked in. On the other hand, calls may get treated differently depending on whatever. I now made sure that there is not extra stuff in the Server header, as some strings of my own git branches had sneaked in, which could possibly confuse upstream servers in case they really evaluate this header. Though, nothing to test yet.
We’re handling and providing support for about ~100.000 calls a day (not with Asterisk) - but we never support sporadic problems with cellphones - it’s time wasting. Nobody cares about temporary broken calls to cellphones (my experience).
I compared your 200 Ack with mine - I couldn’t see any relevant difference, too. It’s a pretty normal 200 Ok to me with seemingly correct IP addresses (no not reachable local IP-address):
In case there would not be the proper external address, Telekom would handle the media by means of connected media tricks. I’ve checked both scenarios a while ago and found that it doesn’t really matter what you use.
I could see different behavior regarding AllIP - you’re using the SIP trunk. Good to know.
The AllIP INVITE contains the provider name of the Caller. I don’t know if you get them as SIP trunk customer, too. If yes, can you say, that the sporadic problems can be seen with any provider or always with the same?
The AllIP product is generally a bit more critical, but I service mainly trunks. I don’t see the caller’s provider, but I happen to know that one of the “critical” callers has a Telekom contract, too.
Meanwhile I can exclude a couple of causes. It looks as if the problem occurs only with mobile phones and it’s always the same phones. So far, I don’t know what triggers the missing ACK, but it is not random (and, again, it happens very rarely).
The next thing would be for me to have a closer look at the phones that cause the problem. That might take some time.
If you can break it down to a dedicated device and if you are able to reproduce it, you should trace it even on the cellphone itself - is there VoLTE in use? Are there sporadic client crashes? I’m pretty sure it’s mostly impossible to figure out the problem without tracing the Caller’s side - honestly, I don’t expect Telekom to do anything (unless you have very good arguments) - but maybe, I’m wrong.
I can exclude that as I heard road noise for one device. My approach is to collect the signalling using HOMER and evaluate as things don’t work as expected.
The problem occurs only for incoming calls, not for outgoing calls to these devices.
