SIP BYE not possible - Protocol mix during a SIP dialog

[cspiel1]

Setup

Instance A sets UDP as default transport protocol via sip_transp_set_default().
Instance B sets TLS as default.

Start a dialog by INVITE from A to B.
Call termination by BYE from B to A.

Issue

The BYE is sent via TLS to port 5060. Then A is not able to process the TLS/SIP BYE at port 5060.

Questions

• (A) Is a protocol mix during a SIP dialog allowed? The RFC-3261 (SIP) does nothing state about the transport protocol in Section 12.2 "Requests within a Dialog".
• (B) Is it allowed to force the transport protocol of following SIP request to the transport protocol of the first SIP transaction in a SIP dialog?

Background

• We shortly added a default SIP transport protocol setting. This currently is used for each SIP request if no ;transport= parameter is given.
• Without this setting the default is UDP, like it was before this setting was added.

Possible Solution

Currently already e.g. the port number of the dialog route is used as target port number for the BYE. Should we also store the transport protocol in the sip_dialog and use this for following SIP requests during a dialog?

[TheQue42]

Hi, I hope I can ask a question associated with this fix. I am in the process of evaluating a sip-stack for a project, and baresip/re looks really interresting.

Does this mean the sip-stack will NOT perform transport selection according to sip-rules, when sending in-dialog requests, since it seems to "remember" the transport selected during initiation??

IMHO, sending an indialog request SHOULD perform the full transport selection logic based on the route-set or contact-uri, and not just use what was decided for the initial invite.

The initial invite was probably sent to an AoR like user@domain.com, where size, and DNS could point to any protocol, while while a contact or RecRoute in the 1xx/2xx could contain both ;transport parameters, ip-addresses, and a different packet-size, causing that request to use another transport protocol, which is completely according to the rules.

[cspiel1]

The ;transport=xxx parameter overrules everything what the linked PR/commit does. The intention was that if default transport protocol is chosen differently on both sides, that it is selected only by the initiator of the SIP dialog.

[TheQue42]

Ok, that sounds at least somewhat better, but only the transport-parameter? After all, if default starts/selects TCP (maybe to a local outgoing proxy that doesn't record-route), and the contact in the 1xx/2xx contains ip and/or port we SHOULD use UDP, and with a pure fqdn then naptr could select something else (providing we dont have RecRoutes).
And vice-versa; with a default choice of UDP, the size of a reinvite might exceed 1300...