After deploying many PBXs, I have never experienced such issues with a provider as I have with this one. I am hoping someone can explain to me if they know the issue or if it is something we can fix PBX end.
Basically, normal calls inbound and outbound work fine with audio, however there is one number (Germany non geographic) that when we call, there is no audio, so after 30s the call is dropped.
Having checked a wireshark capture, I see that the provider do not send any stream over the RTP session:
PBX IP: 192.168.222.3
SIP Trunk IP: 192.168.222.2
They have came back to me and explained:
If the Re-INVITE comes from the B-side without SDP, your equipment sets up an SDP offer, which is correct, but the version in the o-line would have to be incremented (at least 313269269 in this case).
From the capture above, there does not look to be a Re-INVITE sent from the B side. Even if there was, is there any way to change the way that our SDP sends the o-line mid call? I think they are just trying to put the issue down to our system, but the number we need to dial is critical to the business.
It would help to see the full packet capture for this if youâre able to provide it. Seeing the capture of a similar but successful outbound call would also be helpful for comparison. Are you located in Germany? If not, have you tried any other German numbers to see if thereâs some consistency?
I could send you the packet captures of a normal call and a call to this number if it helps?
We logged a ticket with our SIP provider and they have analysed both captures and they believe that the Re-Invite is coming from the B-Side which they deliver to us.
Up to this point everything is correct but in our answer 200OK we see that the Session Version remains the same as in your initial Invite.
Call example:
Arrival Time: Jun 9, 2020 10:22:15.51 W. Europe Daylight Time
A-Number: +49911XXXXXX
B-Number:+4990XXXXXX
Initial INVITE:
SDP Owner/Creator, Session Id (o): - 2140932279 2140932279 IN IP4 [X.X.X.X]
Media Description, name and address (m): audio 64790 RTP/AVP 0 8 3 111 9 101Media Description, name and address (m): audio 64790 RTP/AVP 0 8 3 111 9 101
200 OK after Re-INVITE:
SDP Owner/Creator, Session Id (o): - 2140932279 2140932279 IN IP4 [X.X.X.X]
Media Description, name and address (m): audio 64790 RTP/AVP 0 101
They went onto advise that such handling of Session Version in SDP does not conform with the RFC 4566 :
; is a version number for this session description. Its usage is up to the creating tool, so long as ; is increased when a modification is made to the session data.
Due to the fact that the modification was made, it is required to increase the value of Session Version.
They have asked us to check and adjust the behavior of our PBX according to RFC 4566 because they cannot change anything on our side as of now.
So my question now, would be is there a way in FreePBX to check why on RE-INVITE that the session version does not increase? I can see in other call examples that is does. I am not sure why only this specific number block, the REINVITE does not increase the session version.
Iâm thinking there might be something within the packets that could give some clues as to why the sdp ssession version behavior is different for that call. Maybe the ReInvite packet might be worth comparing with one in a working call. Iâm donât know anything specific to look for, but there could be a notable difference somewhere.
Is the trunk that is calling this number set up as chan_sip, or pjsip? If itâs chan_sip, you may want to try testing the call on a pjsip setup. Or, you can also look further into this option âignoresdpversion=yesâ if it is not already set. It should be treated as no by default, but Iâm seeing some cases where people had to enable to to get things working in some environments.
Thanks @wmoon ⌠we use pjsip for our SIP trunks and AFAIK there is no option to ignore sdp version, since this is a chan sip flag. Would you know of any other setting in PJSIP that could be changed to acknowledge the sdp version?
The problem I have is that very few calls we make, require a re-invite, therefore I worry this could be a problem when any re-invite occurs.
I have sent you the problem pcap file in a direct message, perhaps you may see something I didnt? I can also include a working call, however since there is no re-invite, there is no reason to increment the session.
What I would add, is that as a workaround, we route the call to another PBX out via a Vega 200G gateway which convers ISDN Pri to SIP and we have no problems with the number here. Perhaps a pcap of the gateway might help us?
Yeah, I wasnât seeing any obvious equivalent of that setting for PJSIP either, at least none that stuck out to me. There may be something that Iâm not aware of. I figured it wasnât an issue for pjsip based on the lack of info I was seeing. Iâm not sure if it would help either, but I guess looking at a pcap at the gateway canât hurt. This is assuming the call eventually made out of the same SIP provider. In the meantime, do you know what version of asterisk youâre running? It should show up when entering the Asterisk CLI, or running this command from the terminal:
Yep, we are running v13.32.0
Asterisk 13.32.0 built by mockbuild @ jenkins7 on a x86_64 running Linux on 2020-03-20 19:19:15 UTC
Would you recommend going to 16? I am currently only running v16 in a new environment that has been recently deployed. Having quickly checked the change log I see the below:
2020-06-17 03:58 +0000 [6777ec0340] Joshua C. Colp [email protected]
* res_pjsip_session: Preserve label on incoming re-INVITE.
When a re-INVITE is received we create a new set of
streams that are then swapped in as the active streams.
We did not preserve the SDP label from the previous
streams, resulting in the label getting lost.
This change ensures that if an SDP label is present
on the previous stream then it is set on the new stream.
I think without a PCAP of the call (scrubbed of course) itâs hard to determine if thereâs an Asterisk bug or if this is a config/implementation issue of some sort.
After looking at the pcaps that were sent, I wasnât able to see anything noticeable other than what you already mentioned. It looks like youâre already on a recent version of asterisk, 13.32.0. As for trying 15, I wasnât seeing any particular changes that could apply for this. If youâre using âasterisk-version-switchâ, at this time, you wouldnât see a change as recent as the one you mentioned. And as mattf said, it may not be relevant. Having said that, trying 15 could still be worth a shot if no other ideas come up. My current recommendation is to bring up this issue in the asterisk community boards (https://community.asterisk.org/). Iâm hoping they can verify if the lack of session version updating is an actual issue as the provider is suggesting. They might also be able to tell us if thereâs a pjsip option that could be relevant to this.
There is code already present for increasing the session version number when creating SDP, and the option in question in chan_sip is for when we receive an offer. Itâs entirely possible this is some off-nominal weird scenario. A sanitized PJSIP log (pjsip set logger on) would be the most useful thing. It can be filed on the Asterisk issue tracker[1] along with information on the specific scenario.
