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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
