Is your feature request related to a problem? Please describe.
Yes.
The SIP component in esp-adf currently only supports predefined SIP message types (REGISTER, INVITE, etc.) with limited control over headers and body content.
For many IoT and alarm/notification use cases, I need to send different SIP methods such as SIP MESSAGE, and I must be able to configure headers like Accept, Content-Type, and provide a custom payload.
The current API does not allow this level of control, which prevents interoperability with servers expecting specific SIP MESSAGE formats.
Describe the solution you'd like
I would like the SIP API in esp-adf to support:
-
Custom SIP method selection
Example: "MESSAGE", "NOTIFY", "OPTIONS", etc.
-
Configurable headers, including at least:
Accept
Content-Type
Content-Length (auto-calculated if possible)
-
Arbitrary payload/body data (text, JSON, XML, or binary depending on Content-Type).
Possible API additions could look like:
esp_rtc_sip_message_info_t msg = {
.method = "MESSAGE",
.content_type = "application/scaip+xml",
.accept = "application/scaip+xml",
.payload = "<mrq><ref>1234</ref><cid>123456</cid><dty>0001</dty><stc>001</stc></mrq>"
};
And a dedicated function:
esp_rtc_sip_send_message(esp_rtc_handle_t esp_rtc, const esp_rtc_sip_message_info_t *sip_set_info);
The SIP stack would then assemble the final SIP packet automatically, keeping session handling intact.
Describe alternatives you've considered
-
Using the special field to fake extra headers: insufficient, since the SIP method cannot be changed and some headers remain controlled by the stack. Moreover, currently esp_rtc_sip_message_info_t is only used to customize headers for INVITE method called via esp_rtc_call().
-
Opening a separate UDP/TCP socket and manually crafting SIP packets: this bypasses the SIP session management and defeats the purpose of using ADF.
None of these alternatives provide a clean, sustainable way to send different SIP message types with custom headers and payloads.
Additional context
My use case requires sending SIP MESSAGE requests to a server with a specific Content-Type and a defined payload (e.g., JSON or text data).
This is common in alarm systems, IoT alerting, device-to-server notifications, and lightweight SIP messaging.
Adding this flexibility would make esp-adf suitable for many more industrial and IoT integrations.
Moreover, I need to receive and parse SIP MESSAGE requests from the server. Apparently, it's possible to use int esp_rtc_read_incoming_messages(esp_rtc_handle_t esp_rtc, esp_rtc_sip_message_info_t *sip_read_info); to read incoming SIP messages, but currently, I don't see when this function must be called. After ESP_RTC_EVENT_INCOMING event ? Or is there another event for incoming SIP MESSAGE requests?
Is your feature request related to a problem? Please describe.
Yes.
The SIP component in esp-adf currently only supports predefined SIP message types (REGISTER, INVITE, etc.) with limited control over headers and body content.
For many IoT and alarm/notification use cases, I need to send different SIP methods such as SIP MESSAGE, and I must be able to configure headers like Accept, Content-Type, and provide a custom payload.
The current API does not allow this level of control, which prevents interoperability with servers expecting specific SIP MESSAGE formats.
Describe the solution you'd like
I would like the SIP API in esp-adf to support:
Custom SIP method selection
Example:
"MESSAGE","NOTIFY","OPTIONS", etc.Configurable headers, including at least:
AcceptContent-TypeContent-Length(auto-calculated if possible)Arbitrary payload/body data (text, JSON, XML, or binary depending on
Content-Type).Possible API additions could look like:
And a dedicated function:
The SIP stack would then assemble the final SIP packet automatically, keeping session handling intact.
Describe alternatives you've considered
Using the
specialfield to fake extra headers: insufficient, since the SIP method cannot be changed and some headers remain controlled by the stack. Moreover, currentlyesp_rtc_sip_message_info_tis only used to customize headers for INVITE method called viaesp_rtc_call().Opening a separate UDP/TCP socket and manually crafting SIP packets: this bypasses the SIP session management and defeats the purpose of using ADF.
None of these alternatives provide a clean, sustainable way to send different SIP message types with custom headers and payloads.
Additional context
My use case requires sending SIP MESSAGE requests to a server with a specific Content-Type and a defined payload (e.g., JSON or text data).
This is common in alarm systems, IoT alerting, device-to-server notifications, and lightweight SIP messaging.
Adding this flexibility would make esp-adf suitable for many more industrial and IoT integrations.
Moreover, I need to receive and parse SIP MESSAGE requests from the server. Apparently, it's possible to use
int esp_rtc_read_incoming_messages(esp_rtc_handle_t esp_rtc, esp_rtc_sip_message_info_t *sip_read_info);to read incoming SIP messages, but currently, I don't see when this function must be called. AfterESP_RTC_EVENT_INCOMINGevent ? Or is there another event for incoming SIP MESSAGE requests?