I've been working on the SIP over TLS and SIP over WebSockets (with TLS) in reSIProcate and I'm looking at ways to make it easier people to use both HTTPS and SIP(S) on a single IP/port
There are already methods (e.g. sshttp) that allow SSH and HTTPS on the same port - this works fairly easily without code changes and it is able to preserve the source IP, simply because SSH clients do not send any ClientHello (SSH is not TLS) Multiplexing two TLS server processes is slightly more trouble though Server Name Indication (SNI) is useful for those cases where there is a different domain for both SIP and HTTPS. Where this is applicable, sshttpd could be modified to route the request to the correct server. However, that is not usually optimal: these days, many people want their site to be https://example.org and their SIP (or XMPP) address to be u...@example.org and in that case, SNI will use the same domain for both HTTPS and SIP. This brings me to the observation that something needs to do the TLS handshake and then look at the request body from the client (e.g. the HTTP request line or SIP request line) to work out what type of request it is. All of the following are obviously very easy to distinguish from each other: HTTP: GET / HTTP/1.1 SIP: INVITE sip:dan...@pocock.pro SIP/1.0 XMPP: <?xml version='1.0'?><stream:stream ... xmlns='jabber:client' ... so there may be two ways to go about this: a) the user's preferred process (possibly Apache httpd) will do the handshake, inspect the request line and then tunnel the data stream to some other server when appropriate b) some new process would be created (like sshttpd) to do the handshake and then route the data to whichever server is appropriate (httpd, SIP proxy, XMPP server, ...) In either case, it is very desirable for the process that does the handshake to relay some data about the client (source IP, client certificate identity parameters) to the process that is responsible for the protocol. Is anybody aware of any existing work in any of these areas, even if it is just discussion about the optimal architecture or the type of solution that the Apache community would prefer if somebody worked on this?
