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.
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.
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.
I was having the same issue with incoming conference calls from a Cisco Call Manager.
It seems that it was fixed recently (ASTERISK-30193):
Description
Currently chan_pjsip on receiving a re-INVITE without SDP will only return the codecs that are previously negotiated and not offering all enabled codecs.
This causes interoperability issues with different equipment (e.g. from Cisco) for some of our customers and probably also in other scenarios involving 3PCC infrastructure.
Standard reference
The RFC 3261 states that a UAS SHOULD behave as it would be a new call, i.e. returning all available codecs.