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
INVITE ->
100 Trying <-
401 Unauthorized <-
ACK ->
INVITE (SDP) ->
The 16.15 sequence is similar, except that the second INVITE does not include the SDP.
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.
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.
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.
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: https://gist.github.com/jwhite66/e793ea12a247e11a54a54358a8883bb1#file-bad-txt
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).
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 signup.asterisk.org just spins and spins for me the two times I’ve tried it.
