The sections you are looking for are https://www.rfc-editor.org/rfc/rfc3261.html#section-13.2.2.4 and https://www.rfc-editor.org/rfc/rfc3261.html#section-12.2.1. ACK for 2XX response is a new request within the dialog. Its destination is independently evaluated based on the route set (Contact and Route headers in 2XX response). If the Contact header for 200 OK response has a sip URI with port 5061 and no transport parameter, then ACK MUST be sent using UDP to port 5061. The original URI for INVITE and VIA headers for 2XX are all irrelevant.
Also, please note that "transport=tls" is deprecated (see https://datatracker.ietf.org/doc/html/rfc3261#section-26.2.2). To summarize, you are dealing with a non-compliant or misconfigured provider (using tranport=tls in the INVITE) and the SBC (not providing sips URL in the contact when listening on TLS port only). Best Regards, _____________ Roman Shpount On Tue, Aug 29, 2023 at 12:00 PM <sapellegr...@cox.net> wrote: > The dilemma I have is a UAC (service provider) sends an INVITE with > transport=tls in the Request header as well as in the Contact header, using > the SIP: URI scheme (not SIPS:). > > > > The UAS (an SBC) responds with a 200 OK, but it's Contact header doesn't > provide a transport parameter, just a SIP: URI with IP and port (5061). > However, the Via: header does reflect TLS (there are no Record-Routes). > > > > The UAC responds with the ACK, but because the transport parameter isn't > listed in the 200 OK Contact header, the UAC sends it UDP instead of TLS. > > > > The UAS then discards this as it's listening only on port 5061 (signaling > port is strictly TLS over TCP, no UDP). > > > > The service provider insists that the Contact header on the SBC's 200 OK > needs to specify transport=tls, and by not specifying it, the SBC changes > the transport mid-dialog, regardless if it has the default port for TLS > 5061, and TLS is specified in Via: header. Thus why they send the ACK UDP > which then isn't received. > > > > This call flow is setup similarly for several other SBC clientele, and this > is the first time ever to have this problem. Others respond with the ACK > using TLS even though transport=tls isn't a parameter in the 200 OK's > Contact header, but does have port 5061 and TLS listed in Via: header. > > > > I've been reading through RFC 3263 as well as 3261 sections 18 & 19, but > I'm > not finding anything definitive that a UAC MUST or SHOULD send the ACK > using > the same transport as INVITE, Via header, or default port when it's not > directly indicated within the SIP reply's Contact header. or that by not > specifying transport=tls in the Contact header on a SIP reply (200 OK), > that > then changes the transport to UDP. > > > > Any suggestions on RFC sections or threads that my provide better clarity > on > this particular dilemma? > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
