Hey. ATM Im not able to access more than mail, but from what you wrote:
I'd look up how UAS should/must treat the "transport" param. This does awfully reek of frivolous "SHOULD" keyword being a culprit. On one hand, responding with SIP rather than SIPS, when client requests TLS looks like some sort leniency just so communication could be established, on other hand, personally I'd look at it as a protocol/UAS flaw. So Id say UAS should reply with some error code, either respond with 406+info or 5xx(503). Bartosz Baranowski Red Hat R & D ================================== Word of criticism meant to improve is always step forward. On Tue, Aug 29, 2023 at 6: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
