SIP BYE not possible - Protocol mix during a SIP dialog about re HOT 3 CLOSED

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 [email protected], 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.

from re.

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.

from re.

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...

from re.