SDP Answer Uses Wrong Dynamic Payload Type for H264 and no incoming SIP MESSAGE event callback

[bhupiister]

Problem

Incoming SIP video calls fail or are immediately terminated when the remote side offers H264 using a dynamic RTP payload type other than 96.

The stack appears to hardcode H264 RTP payload type 96 in the SDP answer instead of using the payload type negotiated in the remote offer.

This causes interoperability issues with Asterisk/Wazo/SIP.js.

---

Expected Behavior

If the remote SDP offer contains:

m=video 11692 RTP/AVP 108 100 99
a=rtpmap:99 H264/90000

then the SDP answer should reuse payload type 99:

m=video 21679 RTP/AVP 99
a=rtpmap:99 H264/90000

The RTP sender should also transmit H264 packets using payload type 99.

---

Actual Behavior

The implementation always answers with payload type 96:

m=video 21679 RTP/AVP 96
a=rtpmap:96 H264/90000

even though the remote side offered H264 as payload type 99.

After ACK, Asterisk immediately sends BYE and terminates the call.

---

Logs

Remote Offer

m=video 11692 RTP/AVP 108 100 99
a=rtpmap:108 VP9/90000
a=rtpmap:100 VP8/90000
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F

ESP32 SDP Answer

m=video 21679 RTP/AVP 96
a=rtpmap:96 H264/90000

Call Teardown

Immediately after ACK:

BYE sip:110@192.168.8.103:11162;transport=UDP SIP/2.0
Reason: Q.850;cause=16

---

Notes

Audio negotiation succeeds correctly.

This issue only affects video negotiation due to incorrect dynamic RTP payload mapping.

The implementation should:

1. Parse offered payload IDs
2. Select matching codec
3. Reuse the offered dynamic payload type in SDP answer
4. Use the negotiated payload type during RTP transmission

Hardcoding payload type 96 breaks interoperability with many SIP/WebRTC/Asterisk endpoints.

[TempoTian]

Yes, it is a bug, we can fixed it in next version.

[bhupiister]

Yes, it is a bug, we can fixed it in next version.

Is a quick patch possible? I am currently evaluating esp32p4 chip for my product, and this is the only bottleneck so far.

[TempoTian]

I can build a test version for you, for release it needs wait for sometime, is it OK for you.

[bhupiister]

I can build a test version for you, for release it needs wait for sometime, is it OK for you.

Yes, thank you, perfectly fine for me.
I am using esp32P4 right now.

[TempoTian]

rtc_support_customized_payload_type.zip Try this lib to verify whether it meets your request. I also add a simple UT to cover the cases through P2P mode.

[bhupiister]

rtc_support_customized_payload_type.zip Try this lib to verify whether it meets your request. I also add a simple UT to cover the cases through P2P mode.

Hey, the patch is working fine. Thank you for the quick fix and timely response. I will close this for now and hope this will be part of the new release.

[bhupiister]

@TempoTian
Can you make one more possible edit for esp32p4?

I am using the ESP SIP component on ESP32-P4. SIP calls work, but I need to handle in-dialog SIP MESSAGE requests for text/chat during an active call.

Currently, I do not see a public SIP event for incoming MESSAGE requests, so I have to parse/scrape SIP log output to detect message bodies and dialog headers. This is fragile.

Could the SIP component expose an event from _esp_sip_event_handler() or equivalent when an incoming SIP MESSAGE is received?

Ideally, the event would include:

message body
Call-ID
From
To
CSeq
content type
whether it belongs to the current dialog
Example event name could be something like:
SIP_EVENT_MESSAGE_RECEIVED

This would allow applications to handle SIP text messages without parsing internal logs.

[bhupiister]

Look at this fix #1556 (comment)
Please combine this with the fix you already made for the dynamic payload for h264.