On 23 Apr 2014, at 8:39 PM, Daniel Pocock <dan...@pocock.pro> wrote: > 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?
Not aware specifically about anything like this, but it is certainly possible to do this. What you want is a connection filter that looks out for "INVITE * SIP/1.0" and then handles the connection if seen in some fashion, even if this is as simply as proxy the connection to a real SIP server. Same is possible with XMPP. Sounds like a sensible thing to do. Regards, Graham --
