Issue with no audio on one specific number

siptrunk
Tags: #<Tag:0x00007f7028c49600>
(United Kingdom) #1

Hi all,

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
image

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.

Thanks in advance :smiley:

#2

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?

(United Kingdom) #3

Hi @wmoon

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.

Thanks
A

#4

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.

(United Kingdom) #5

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?

(United Kingdom) #6

Ah, it seems that you are not accepting messages at the moment… :frowning:

#7

Can you try now? I had them disabled.

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:

asterisk -rx “core show version”

(United Kingdom) #8

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 jcolp@sangoma.com

* 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.
(Matthew Fredrickson) #9

That commit message is only applicable to webrtc related SDP info and would not help with your problem (IMHO).

(Matthew Fredrickson) #10

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.

#11

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.

(Joshua C. Colp) #12

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.

[1] https://issues.asterisk.org/jira

(United Kingdom) #13

Thanks - I am going to do further tests this week to rule out any config (that I can think of)

Once done, if it still doesn’t work, I will file something under the Asterisk issue tracker. Thanks for all your help.

(system) closed #14

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.