Use NUTAG_AUTO_INVITE_100 even for INVITE with Timestamp header

[fulhade]

I've noticed that Sofia respond with '100 Trying' even if NUTAG_AUTO_INVITE_100 is used (<param name="auto-invite-100" value="false"/> in FreeSWITCH SIP profile) when Timestamp header is present in INVITE request.

[garacil]

Reviewed against the source and the RFC — this is correct and minimal. 👍

In nua_stack_process_request() the auto 100 Trying is sent when (method == sip_method_invite && nh->nh_prefs->nhp_auto_invite_100) || sip->sip_timestamp (nua_server.c:264-270). The unconditional sip->sip_timestamp clause means an INVITE that carries a Timestamp header always gets an auto 100, bypassing NUTAG_AUTO_INVITE_100 — documented specifically as "Enable/Disable automatic 100 Trying when receiving INVITE" (nua_params.h:120-121, nua_tag.c:2868-2874).

That override isn't required by the RFC: RFC 3261 §8.2.6.1 only says that when a 100 is generated the Timestamp MUST be copied into it — it does not make a Timestamp force a 100; §20.38 defines no normative behaviour that would. So gating the clause to non-INVITE (sip->sip_timestamp && method != sip_method_invite) is the right fix: the INVITE wire-100 becomes governed solely by NUTAG_AUTO_INVITE_100, while the pre-existing Timestamp/RTT 100 for non-INVITE requests is preserved. The unconditional SR_STATUS1(sr, SIP_100_TRYING) a couple of lines up only sets the internal provisional status; nothing goes on the wire when the nta_incoming_treply() inside the predicate is skipped — exactly the auto-invite-100=false behaviour.

LGTM — smallest safe fix for the reported issue. (We hit the same behaviour integrating Sofia-SIP into GABPBX's chan_sofia.)

Minor and out of scope here: RFC 3261 §8.2.6.1 also says a UAS SHOULD NOT issue provisional responses for non-INVITE, so the retained "Timestamp forces 100" for non-INVITE is legacy behaviour that could be revisited separately.