Symmetric payload type in generating SDP answer

[bennylp]

Answerer SHOULD use matching payload type as the offer:

• RFC 3264 6.1:

In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer.

• RFC 6184:

To simplify the handling and matching of these configurations, the same RTP payload type number used in the offer SHOULD also be used in the answer, as specified in [8]. An answer MUST NOT contain the payload type number used in the offer unless the configuration is exactly the same as in the offer.

Note:

• Implemented in SDP negotiator (instead of in endpoint as the preanswer generator), as the codecs need to be negotiated first.
• Initiating re-INVITE will revert the payload type numbers to the pjmedia defaults, which should be fine. If this is not acceptable, a simple solution will be providing alternatives for SDP generation for the re-INVITE:
  • using active local SDP,
  • no SDP.

[nanang]

(In [3837]) Re #1300: Implemented symmetric payload type in generating SDP answer in SDP negotiator.
This should work for all codecs, audio & video. Can be disabled at compile-time
using PJMEDIA_SDP_NEG_REWRITE_ANSWER_PT macro setting.

[bennylp]

(In [3842]) Re #1300: fixed bug when looking for non-telephone-events codec in the incoming INVITE causing it to rejects with 488

[nanang]

(In [3856]) Re #1300: Bug in updating SDP rtpmap in symmetric PT when PT offer is shorter than our default, the rtpmap value length was not updated.