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
