[asterisk-dev] Asterisk 16 / pjsip: actual SDP handling in case of late offer during outbound call seems to break call

[Michael Maier]

Hello!

I'm facing a problem on an outbound call which receives a reInvite w/o SDP (late / delayed offer technique) from ISP. The ISP won't provide
any SDP in the following received ACK and the call is broken therefore afterwards because no more media is sent after this reInvite.


Detail:

- ISP sends ReInvite w/o SDP
- Asterisk sends 200 OK containing the SDP, received by the initial 200 OK from the ISP before
  (which is a subset of the defined allowed media for this trunk).
  The <sess-version> in the SDP of the 200 OK as answer to the reInvite is the same as the one of
  the initial INVITE though the SDP is different. Shouldn't <sess-version> be increased if SDP
  is changed changed?
- ISP sends an ACK - but w/o SDP -> Call is dead from now on.


RFC6337, 5.2.5. Subsequent Offers and Answers

In the "o=" line, only the version number may change, and if it
changes, it must increment by one from the one previously sent as
an offer or answer. (Section 8 of [RFC3264].) If it doesn't
change, then the entire SDP body must be identical to what was
previously sent as an offer or answer. Changing the "o=" line,
except version number value, during the session is an error case.
The behavior when receiving such a non-compliant offer/answer SDP
body is implementation dependent. If a UA needs to negotiate a
'new' SDP session, it should use the INVITE/Replaces method.


I tested another SIP client (directly connected to the ISP), which has been working. This SIP client always sends the complete SDP after
ReInvite and nevertheless always increases <sess-version>.



Thanks
Michael