INVITE without early offer SDP in Asterisk 16.15

I’m trying to upgrade from Asterisk 13.2 to Asterisk 16.15 (Debian Stretch to Debian Bullseye).

I have a trunk provider that I connect with pjsip. They require: “Send SDP using the Early Offer method in initial SIP Invite.”

Outbound calls fail on 16.15 but work on 13.2. Using sngrep, the difference seems to be that 13.2 would send SDP with an early invite, but that does not seem to happen on 16.15.

That is, the 13.2 sequence is
100 Trying <-
401 Unauthorized <-
ACK ->

The 16.15 sequence is similar, except that the second INVITE does not include the SDP.

Any advice or insight is appreciated.

I believe Asterisk only uses early offer as UAC (although it will accept late offer as UAS). The second INVITE in your example is still an initial request. I believe it would be a bug if it didn’t contain an SDP offer, but I think people would need to see the full contents of the two INVITEs to be convinced.

The ITSP’s system is broken if it doesn’t support late offer.

Thanks for the reply. I’m going to attach two log files; one a failure with 16.15 and one from 13.2 that works. The pjsip.conf files are essentially identical (they differ with some experimentation I’ve done with a webrtc client, but nothing to do with the trunk endpoint).

Switching providers is a relatively tough thing to swallow. They are not especially asterisk aware, but they have otherwise been quite good to us. But I will start that exploration.

I still remain puzzled as to why the the newer version behaves differently; even if I had to patch asterisk to restore the old behavior, that would likely be a more palatable immediate result for me.

p.s. I’m too new to attach. So [link to failure]:frowning: And [link to success]:frowning:

My suspicion is that a packet size limit has been exceeded and either it has not added the SDP, but failed to produce an error message, or it is falling back to late offer in the hope of being able to produce a shorter response.

This pretty much has to be significant:

[Dec 5 12:57:16] ERROR[54667]: res_pjsip_session.c:900 handle_incoming_sdp: PJSIP/popptrunk-0000000e: Couldn't negotiate stream 0:audio-0:audio:sendrecv (ulaw|alaw|g729|amr|amrwb|codec2|g723|gsm|g726|g726aal2|adpcm|slin|slin12|slin16|slin24|slin32|slin44|slin48|slin96|slin192|lpc10|speex|speex16|speex32|ilbc|g722|siren7|siren14|testlaw|g719|opus|silk8|silk12|silk16|silk24)

but I don’t understand why it didn’t error earlier, unless, maybe it is only reporting a problem at a debug level.

Most people would limit the number of codecs offered, which might explain why this isn’t often seen.

I have experimented with limiting the codecs, which did not appear to make a difference. And, again, 13.2 works fine with the identical configuration.

Is there a place in the code I can see where that packet size limit would apply? And, in general, is there a right place to look? It seems like there is code in channels/chan_pjsip.c, a lot of code in res/pjsip.c, and then additionally code in /third-party/pjproject. It’s not clear to me if there would be an easy place to hone in on this.

Also, I believe you are right that the message is significant, but my read of it is that this is the point where we corroborate my providers claim that they require early offer SDP. That is, they appear to be responding with a fairly broken SDP packet. In the ‘good’ case, my provider returns an SDP packet with a PCMU codec, and things go on to work.

I hadn’t read as far as the internal error; looks like both sides have issues.

However, they did respond with PCMU (and G729), but without rtmap, which is optional for well known codec numbers. What they haven’t done is to reject the video stream, which they don’t know about.

I’ve found a few bread crumbs that give me a partial understanding of what is happening.

Specifically, when the SDP is being added to the invite in res_pjsip_session.c
the code does not check the return code from pjsip_inv_set_local_sdp; the sdp is just silently stripped from the invite if that fails. In my case, it is failing because a validation of the rptmaps of the media formats fails:

That fails because I have 5 codecs in the media description fmt_info that do not have rtpmaps. The 5 are codec2 (98), testlaw (113), silk8 (114), silk12(120), silk16(99) and silk24(100), although the code exits when it hits the first one, codec2. I’ve stashed a copy of the failing media description here:

There is some suggestion that pjmedia has it wrong; this comment seems to suggest that rtpmaps are optional:

If I comment out the check in pjmedia here:
then my phone system starts working as I expect it to.

Things I do not yet understand include why this changed between 13.2 and 16.15 and how I could disable the codecs to prevent this. A quick analysis of the code shows little difference. However, when I look at the media format from a the ‘good’ case, I’m a bit puzzled to see that type 98 is h263-1998. There seems to be some indication that types >= 96 are dynamic and so should be expected to change, so perhaps that is expected. I also do not yet understand what causes a codec to get into the format line; my naive attempts to disable the troublesome ones don’t seem to help. But I am out of time to research further today; I thought I would post what I have found so far, in the hopes that someone with more knowledge might now be able to say ‘aha!’ there is your problem.



I think these are testing values not real ones, which is why there is no map name for them. I expect the other high numbered ones will have rtpmaps.

Most people disallow all and then just add the ones they want. As you haven’t said how you are disabling the codecs, I can’t really say why that is not working.

Yes it will be correct that numbers < 96 are well known, and don’t need an rtpmap. That’s why I commented that the offer from the other side was OK with 0 and 18 but no corresponding rtpmaps.

I wonder if the change could have been from Asteirsk itself generating the rtpmap list to PJSIP doing so. In your working example you have rtpmaps for all the well known codecs, but the code you referenced would have suppressed those.

That then begs the question as to how does PJSIP get to know the codec numbers of the codecs Asterisk allocates to the dynmic range. Maybe the code got broken for all of them, but most people don’t use them with SIP.

The res_pjsip_sdp_rtp module retrieves and adds them in. Entirely possible that for some it’s not doing that properly, specifically seldom used/shouldn’t be used codecs (such as codec2, testlaw, etc).

It’s not broken for all of them.

I just wanted to follow up on this, as I was able to spend time on this over the past weekend.

I’m unsure what I did incorrectly the first time, but the straight forward disallow=all, allow=X configuration on the endpoint worked when I tried it this weekend.

With that said, I’d like to submit a patch to asterisk to provide at least a warning message when pjsip_inv_set_local_sdp() fails. But just spins and spins for me the two times I’ve tried it.

I’ve reported being unavailable.

This should now be resolved.

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