SIP Offer Answer Model

Question

I am having a confusion regarding SIP Offer-Answer model. The scenario is like this.

I configured two accounts on my client side (Say A and B) with asterisk server and making a call from A to B.

Account Details of A

Client Side(Application) : A having video codec H264, Audio codecs G722,G711

Server Side(Asterisk) : No video Codec, Audio codecs G722,G711

Account Details of B

Client Side(Application) : No video Codec,Audio codecs G722,G711

Server Side(Asterisk) : No video Codec,Audio codecs G722,G711

In the first INVITE(offer) i am sending the SDP with "m=" parameter for both audio and video (video port as 52162) and asterisk is sending me the answer with "m=" parameter for both audio and video (video port as 0) on 183 session progress and 200 OK, (because asterisk is not having any video codec).

From application side i am sending next INVITE to put the call on hold. For that i am sending a=sendonly and "m=" parameter only for audio.

My doubt is "Can I avoid from application side "m=" parameter for video for the second INVITE(in my case it is hold)", if i am getting answer with video port as 0 for the first offer.

Answer 1

The SIP offer/answer model requires that you re-use all m= lines in same order in all modifications of the session.

The only allowed action is to add additional m= lines below the existing ones.

In your use-case, if you don't include the m=video line, the remote side is supposed to reject your INVITE.

EDIT: Here is the exact wording from the rfc which clearly shows the requirements to never remove any m= lines:

From rfc3264 Section 8 Modifying the Session

If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in
the previous SDP.  In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines.  The i-th media
stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top.  This matching is
necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP.  Because of
these requirements, the number of "m=" lines in a stream never
decreases, but either stays the same or increases.  Deleted media
streams from a previous SDP MUST NOT be removed in a new SDP;
however, attributes for these streams need not be present.

As a sidenote, it's useful to indicate an exception where the m= line type (audio, video, ...) MAY be modified: It's provided in Section 8.3.3 Changing Media Types. This exception is very specific and won't apply in 99,99%... (example from rfc is voiceband fax to fax)