I do have an unexpected problem with some external connections. Only a few calling parties are involved, but I can reproduce the problem to 100% with them.
Immediately after one picks up the receiver to answer the call, Asterisk terminates the ongoing call:
I am using Asterisk 16.5.0 with the pjsip stack and the Asterisk box in the SIP flow diagram has the 80… IP. The external trunk is the German Telekom SIP-Trunk. I’d like to point out again that only a few calls are affected here, so something from the outside seems to trigger this odd behavior.
At first glance, I don’t see a 183, but a 491 and it looks as if there is a superfluous re-Invite or the other side cannot answer the re-Invite properly.
One would need to see the full trace (preferably taken from Asterisk, rather than wireshark, as people are more used to decoding those), but it looks like there was a re-INVITE collision, followed by a completed re-INVITE to which the entity using port 50928 took exception.
If I read this correctly, it is the phone that is terminating the call, not Asterisk.
Easier said that done. I was already happy to catch such a failed call. Meanwhile I’ve set up a logger which I can later analyze. Port 50928 is the Asterisk box in this case and I can follow you, but I don’t know what is causing this—so far.
I’ve got a SIP Trace from the Asterisk box that seems to responsible for the termination.
Currently, I see only two strange things. The first is the 491 that starts at line 813 and the second is a Q.850 cause code of 58 (line 914), which translates to "Bearer capability not presently available ", which may or may not be related to the earlier collision.
I’ve left the entire trace intact, so there are a couple of lines initially that relate to an otherwise unimportant dialgroup.
I am not sure whether I am interpreting the sip trace correctly, but it looks as if Asterisk is responsible for the termination. If I reverse caller and callee and reverse the direction of the call, there are no problems.
Asterisk seems to have deleted the audio media stream (m= with port 0), but I can’t see why. On the other hand, you are making it difficult to debug by using wireshark loggiing rather than Asterisk logging. The Asterisk logs may well eplain what it thinks it is doing.
The response is a bit confused as it seems to be saying held and not held at the same time (as well as delete stream).
Initially I used a pcap trace on the WAN side of the router, the Q850 file is the output of “pjsip set logger on” (my side), which I captured using a temporary logger channel.
I’ll have a more detailed look at the sip messages. At first I thought that everything is fine since the A law codec was already negotiated, but I missed the m field.
I’ve just got a phone call from German Telekom saying that the problem has been solved. The support staff figured out the 491 response independent from myself as well as the collision with the resulting loss of media which then caused the termination. This happened for certain codec combinations, only.
I haven’t tested it yet, but my impression was that the person who called me knew what he was talking about. Maybe calling a hotline makes sometimes sense…
