Hi Kamailians!
I’ve written a very short IETF draft in order to register a SIP TLS ALPN: https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/
An ALPN is a short code used in TLS connection setup to inform the server of the “next protocol” after TLS connection is setup. This way, a server listening to a port, like 5061 and 443, can support multiple protocols on the same port.
In Kamailio, we support HTTP 1 and SIP because they’re very much alike, but if there’s a need to support other protocols it will be hard, like MSRP. With ALPN support we could when using TLS.
In addition, newer versions of HTTP will be harder to support using the same parser. ALPN makes it easier.
I do hope the registration will come through. If so, maybe we can discuss what’s needed to support ALPN for SIP and HTTP in the TLS code.
Cheers, /O
Why not register "msrp" extension in this draft?
Also I think we need customer extension support here. Via TLS we can send Kamailio DMQ messages. Generally we can use "sip" extension, but user defined will be more accurate.
Say we can define extensions prefix "user-defined-"
On Tue, Aug 17, 2021, 6:46 PM Olle E. Johansson oej@edvina.net wrote:
Hi Kamailians!
I’ve written a very short IETF draft in order to register a SIP TLS ALPN: https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/
An ALPN is a short code used in TLS connection setup to inform the server of the “next protocol” after TLS connection is setup. This way, a server listening to a port, like 5061 and 443, can support multiple protocols on the same port.
In Kamailio, we support HTTP 1 and SIP because they’re very much alike, but if there’s a need to support other protocols it will be hard, like MSRP. With ALPN support we could when using TLS.
In addition, newer versions of HTTP will be harder to support using the same parser. ALPN makes it easier.
I do hope the registration will come through. If so, maybe we can discuss what’s needed to support ALPN for SIP and HTTP in the TLS code.
Cheers, /O _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
On 18 Aug 2021, at 11:59, Sergey Safarov s.safarov@gmail.com wrote:
Why not register "msrp" extension in this draft?
Simply because I personally did not need it. But you are right, we do have an MSRP module that can share the same port, very much like XHTTP.
Also I think we need customer extension support here. Via TLS we can send Kamailio DMQ messages. Generally we can use "sip" extension, but user defined will be more accurate.
Say we can define extensions prefix "user-defined-“
I will have to go back to the ALPN rfc and check if there’s any mention of user-defined. THat would propably be a larger addition to the ALPN function, so it would require a full RFC publication.
Thanks for the feedback! /O
On Tue, Aug 17, 2021, 6:46 PM Olle E. Johansson <oej@edvina.net mailto:oej@edvina.net> wrote: Hi Kamailians!
I’ve written a very short IETF draft in order to register a SIP TLS ALPN: https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/ https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/
An ALPN is a short code used in TLS connection setup to inform the server of the “next protocol” after TLS connection is setup. This way, a server listening to a port, like 5061 and 443, can support multiple protocols on the same port.
In Kamailio, we support HTTP 1 and SIP because they’re very much alike, but if there’s a need to support other protocols it will be hard, like MSRP. With ALPN support we could when using TLS.
In addition, newer versions of HTTP will be harder to support using the same parser. ALPN makes it easier.
I do hope the registration will come through. If so, maybe we can discuss what’s needed to support ALPN for SIP and HTTP in the TLS code.
Cheers, /O _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org mailto:sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
I see some registered names contains protocol version. May need use "sip/2" as registered name?
https://medium.com/geekculture/exploring-application-layer-protocol-negotiat...
On Wed, Aug 18, 2021, 2:09 PM Olle E. Johansson oej@edvina.net wrote:
On 18 Aug 2021, at 11:59, Sergey Safarov s.safarov@gmail.com wrote:
Why not register "msrp" extension in this draft?
Simply because I personally did not need it. But you are right, we do have an MSRP module that can share the same port, very much like XHTTP.
Also I think we need customer extension support here. Via TLS we can send Kamailio DMQ messages. Generally we can use "sip" extension, but user defined will be more accurate.
Say we can define extensions prefix "user-defined-“
I will have to go back to the ALPN rfc and check if there’s any mention of user-defined. THat would propably be a larger addition to the ALPN function, so it would require a full RFC publication.
Thanks for the feedback! /O
On Tue, Aug 17, 2021, 6:46 PM Olle E. Johansson oej@edvina.net wrote:
Hi Kamailians!
I’ve written a very short IETF draft in order to register a SIP TLS ALPN: https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/
An ALPN is a short code used in TLS connection setup to inform the server of the “next protocol” after TLS connection is setup. This way, a server listening to a port, like 5061 and 443, can support multiple protocols on the same port.
In Kamailio, we support HTTP 1 and SIP because they’re very much alike, but if there’s a need to support other protocols it will be hard, like MSRP. With ALPN support we could when using TLS.
In addition, newer versions of HTTP will be harder to support using the same parser. ALPN makes it easier.
I do hope the registration will come through. If so, maybe we can discuss what’s needed to support ALPN for SIP and HTTP in the TLS code.
Cheers, /O _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Updated to sip/2
https://www.ietf.org/archive/id/draft-johansson-sip-alpn-02.html
Thanks for the feedback!
/O
On 21 Aug 2021, at 17:04, Sergey Safarov s.safarov@gmail.com wrote:
I see some registered names contains protocol version. May need use "sip/2" as registered name?
https://medium.com/geekculture/exploring-application-layer-protocol-negotiat... https://medium.com/geekculture/exploring-application-layer-protocol-negotiation-alpn-c47b5ec3b419 On Wed, Aug 18, 2021, 2:09 PM Olle E. Johansson <oej@edvina.net mailto:oej@edvina.net> wrote:
On 18 Aug 2021, at 11:59, Sergey Safarov <s.safarov@gmail.com mailto:s.safarov@gmail.com> wrote:
Why not register "msrp" extension in this draft?
Simply because I personally did not need it. But you are right, we do have an MSRP module that can share the same port, very much like XHTTP.
Also I think we need customer extension support here. Via TLS we can send Kamailio DMQ messages. Generally we can use "sip" extension, but user defined will be more accurate.
Say we can define extensions prefix "user-defined-“
I will have to go back to the ALPN rfc and check if there’s any mention of user-defined. THat would propably be a larger addition to the ALPN function, so it would require a full RFC publication.
Thanks for the feedback! /O
On Tue, Aug 17, 2021, 6:46 PM Olle E. Johansson <oej@edvina.net mailto:oej@edvina.net> wrote: Hi Kamailians!
I’ve written a very short IETF draft in order to register a SIP TLS ALPN: https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/ https://datatracker.ietf.org/doc/draft-johansson-sip-alpn/
An ALPN is a short code used in TLS connection setup to inform the server of the “next protocol” after TLS connection is setup. This way, a server listening to a port, like 5061 and 443, can support multiple protocols on the same port.
In Kamailio, we support HTTP 1 and SIP because they’re very much alike, but if there’s a need to support other protocols it will be hard, like MSRP. With ALPN support we could when using TLS.
In addition, newer versions of HTTP will be harder to support using the same parser. ALPN makes it easier.
I do hope the registration will come through. If so, maybe we can discuss what’s needed to support ALPN for SIP and HTTP in the TLS code.
Cheers, /O _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org mailto:sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org mailto:sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org mailto:sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-
Olle E. Johansson -
Sergey Safarov