PJSIP re-INVITE without SDP, Codec Negotiation

I am completing a interop certification for a asterisk application and think I have found an issue with asterisk (15.5.0) running PJSIP. I am testing a scenario when a asterisk pjsip endpoint can pickup an external trunk call.

When receiving a re-invite without SDP, asterisk is responding (SDP in the 200 OK) with the previously negotiated codec and not offering all available.

This link provides some of the RFC’s where this behaviour is expected.
https://lists.cs.columbia.edu/pipermail/sip-implementors/2016-January/030448.html

And I think they issue has been fixed in pjsip a while back.
https://trac.pjsip.org/repos/ticket/1892

Any thoughts, help would be appreciated.

Cheers,

Daniel

Are you sure this is PJSIP. I seem to remember something like this on chan_sip with late offers SDP.

However, I’m not sure this is actually a protocol violation, even though it is suboptimal, as I don’t think anything says the UAS cannot change its mind from invite to invite.

In particular, offering the full set could lead to s situation where there is no codec translation path the the call has to be closed.

That method of SDP Offer/Answer is not commonly done, but I vaguely recall we did it that way for maximum compatibility between endpoints. An option to alter that behavior would be fine, but it would need to default to off.

Cisco Call Manager (or whatever they call it now) uses late offer if it is not forced to include an MTP (codec translation device) in the call.

Incidentally, codecs aren’t negotiated. Each side says what it will accept, and there is no requirement that the codec used in one direction is usable in the other, although most implementations add that constraint.

Yeah, we had to use the same codec on in each direction by default because DSPs in devices like to do a single codec at a time - so they very much can’t do differing codecs even though that’s what the RFC says. Fun times when we added streams seeing how different devices handled things.

Definitely PJSIP, I tried chan_sip but behaviour was a bit weird with call being placed on hold but I will revisit in the morning. I am dialing a feature code to pick up an external call. Asterisk sending …

Send->INVITE with SDP.
Receive->100 Trying
Receive->200 OK
Send->ACK

Then asterisk receives the re(INVITE) with SDP
Receive->INVITE without SDP
Send->200 OK

At this point the it is expected that asterisk should be offering all available codecs but only uses one from current active media session. This is Broadsoft certifications which I thought Asterisk/SwitchVox has previously passed.

Thanks

Daniel

Any pointers on how to make this change? I think its beyond my programming skills, should I create an issue on the tracker? Thanks.

All of the RTP related SDP code is in the res_pjsip_sdp_rtp module. You can certainly create an issue, but there is no time frame on when it would get looked into. This is something people don’t use in practice.