Incoming INVITE failure before call creation does not emit ANY REJECT EVENT

[SnowMaster12]

Hi,

I am wrapping Baresip inside a mobile SDK and I need to expose call failure information to the upper application layer in a consistent way.

For outgoing calls, this works correctly, in fact, when the remote side replies with a SIP error response, the call already exists and I receive BEVENT_CALL_CLOSED. From there I can read the status code using call_scode(call) or, when available, msg->scode.

The case I am looking at is different: an incoming INVITE where Baresip fails while accepting/creating the call.

Today, in this scenario, no BEVENT_CALL_CLOSED is emitted, which is understandable because the failure can happen before the struct call is fully available and before the normal call lifecycle starts.

From the SIP point, the failure exists and is correctly handled, but from the wrapper/application point of view there is no bevent that allows us to notify the SDK user that the incoming call failed with 500 Call Error.

For SDK integrations, it would be useful to expose this kind of failure as a dedicated event, like this:

BEVENT_INCOMING_CALL_FAILED

carrying at least:

scode = 500
reason = "Call Error"
call = NULL
msg = original INVITE

Could this be useful for you too @juha-h ?

[juha-h]

Could be useful, but I haven't noticed that "Baresip fails while accepting/creating the call". What kind of situation can make such a failure?

[SnowMaster12]

I am only referring to the incoming call case.

For outgoing calls, when we initiate the call, a struct call already exists, so remote SIP failures are normally reported through BEVENT_CALL_CLOSED, and we can read the final status using call_scode(call) or msg->scode.

The case I am trying to cover is different:

remote endpoint sends an INVITE → Baresip starts accepting/creating the call → the setup fails before a valid struct call is available.

The situations I had in mind are early incoming INVITE failures, for example:

• ua_call_alloc() fails
• call_accept() fails
• no suitable local address/interface is available
• unsupported address family
• media/RTP allocation or initialization failure
• incoming INVITE is rejected before a call object is created

In these cases Baresip already handles the SIP side correctly and replies to the remote endpoint, for example with:

sip_treply(NULL, uag_sip(), msg, 500, "Call Error");

or, in other early incoming INVITE checks, with responses like 403, 404, etc.

The missing part is when there is no struct call yet, so the app layer cannot observe any event in that case.

[cspiel1]

My first thought about incoming calls was that a CALL_CLOSED should not be sent without a prior CALL_INCOMING.

But if we look in function call_accept() there are indeed a few cases (for SIP 488/481) for which a CALL_CLOSED is emitted without a prior CALL_INCOMING.

And if we like to keep this behavior there is indeed an inconsistency with cases where the control flow reaches:

baresip/src/ua.c

Line 837 in a9b3749

(void)sip_treply(NULL, uag_sip(), msg, 500, "Call Error");

[SnowMaster12]

That line is exactly the silent path I am referring to.
The INVITE is rejected at SIP level with 500 Call Error, but the application layer does not receive any structured event.

I agree that if a struct call exists, emitting CALL_CLOSED is consistent with the behavior, even if CALL_INCOMING was not emitted before.

My only concern is the case where ua_call_alloc() fails before a valid struct call exists.
In that case, CALL_CLOSED may not be the right event because there is no real call object.

But I still think the application should receive a terminal notification for the rejected incoming INVITE.
if call == NULL, we should emit a UA/SIP-level incoming-call-failed event carrying the original INVITE, status code and reason.

[SnowMaster12]

If this approach makes sense to you, I can try to prepare a small PR for it.

My idea would be:

• keep the existing CALL_CLOSED behavior when a struct call is available;
• add a UA/SIP-level event for the case where the incoming INVITE fails before a valid struct call is created;
• include the original INVITE msg, SIP status code and reason phrase in that event.

I can work on an initial implementation and share it for review.

[juha-h]

Makes sense to me. The new event would be similar to BEVENT_SIPSESS_CONN.