[sr-dev] Registering a SIP TLS ALPN

[Olle E. Johansson]

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 at 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-negotiation-alpn-c47b5ec3b419 <https://medium.com/geekculture/exploring-application-layer-protocol-negotiation-alpn-c47b5ec3b419>
> On Wed, Aug 18, 2021, 2:09 PM Olle E. Johansson <oej at edvina.net <mailto:oej at edvina.net>> wrote:
> 
> 
>> On 18 Aug 2021, at 11:59, Sergey Safarov <s.safarov at gmail.com <mailto:s.safarov at 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 at edvina.net <mailto:oej at 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 at lists.kamailio.org <mailto:sr-dev at 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 at lists.kamailio.org <mailto:sr-dev at 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 at lists.kamailio.org <mailto:sr-dev at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20210824/0b856502/attachment.htm>