I found a partial list of supported RFCs on the website. What is the entire list of supported RFCs? This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
On 07/17/2014 11:05 AM, Conners, James wrote:
I found a partial list of supported RFCs on the website. What is the entire list of supported RFCs?
That would be a very challenging question to answer, depending on what is meant by "supported" and what one considers to be an applicable RFC.
What is the real objective of this seemingly specious line of enquiry?
Asking what the "real" objective is suggests there is a hidden reason for my question. I can assure there is no hidden reason. We're simply investigating the possible use of the Kamailio SIP server and would like to know its capabilities and which RFCs it supports. Our current SIP server supports a set of RFCs. So, it seems logical to ask what RFCs an alternative SIP Server supports. The Kamailio website uses the words "Among supported standards:" on its interoperability page. Maybe the folks at Kamailio can provide you with their meaning of the word "supported".
-----Original Message----- From: sr-dev-bounces@lists.sip-router.org [mailto:sr-dev-bounces@lists.sip-router.org] On Behalf Of Alex Balashov Sent: Thursday, July 17, 2014 2:46 PM To: sr-dev@lists.sip-router.org Subject: Re: [sr-dev] Supported RFCs
On 07/17/2014 11:05 AM, Conners, James wrote:
I found a partial list of supported RFCs on the website. What is the entire list of supported RFCs?
That would be a very challenging question to answer, depending on what is meant by "supported" and what one considers to be an applicable RFC.
What is the real objective of this seemingly specious line of enquiry?
-- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
On 07/17/2014 03:19 PM, Conners, James wrote:
Asking what the "real" objective is suggests there is a hidden reason for my question. I can assure there is no hidden reason. We're simply investigating the possible use of the Kamailio SIP server and would like to know its capabilities and which RFCs it supports. Our current SIP server supports a set of RFCs. So, it seems logical to ask what RFCs an alternative SIP Server supports. The Kamailio website uses the words "Among supported standards:" on its interoperability page. Maybe the folks at Kamailio can provide you with their meaning of the word "supported".
If you understand that SIP consists of a core RFC (3261) and hundreds of additional features and extensions specified by other drafts and RFCs, in varying stages of approval and de facto adoption, then you would be able to appreciate that this is not a black-and-white, yes-or-no question.
On 07/17/2014 03:20 PM, Alex Balashov wrote:
On 07/17/2014 03:19 PM, Conners, James wrote:
Asking what the "real" objective is suggests there is a hidden reason for my question. I can assure there is no hidden reason. We're simply investigating the possible use of the Kamailio SIP server and would like to know its capabilities and which RFCs it supports. Our current SIP server supports a set of RFCs. So, it seems logical to ask what RFCs an alternative SIP Server supports. The Kamailio website uses the words "Among supported standards:" on its interoperability page. Maybe the folks at Kamailio can provide you with their meaning of the word "supported".
If you understand that SIP consists of a core RFC (3261) and hundreds of additional features and extensions specified by other drafts and RFCs, in varying stages of approval and de facto adoption, then you would be able to appreciate that this is not a black-and-white, yes-or-no question.
The question is very difficult to answer, for the reasons Alex explained....
The core of Kamailio is an RFC3261 SIP Server.
Adding or using different modules will to the list of RFCs... such as with CPL module (RFC3880), invoking P-asserted-identity (RFC3325), using DNS NAPTR (RFC2915), Websockets (RFC6455), etc.
The ultimate answer to this would depend on your intentions/usages of the product in deployment.
The current stable version of Kamailio offers the following modules:
http://kamailio.org/docs/modules/stable/
You can also search the wiki (http://www.kamailio.org/wiki/start) for specific RFC's that may be of interest.
Fred Posner The Palner Group, Inc. http://www.palner.com (web) +1-503-914-0999 (direct) +1-954-472-2896 (fax)
On 07/17/2014 03:53 PM, Fred Posner wrote:
The question is very difficult to answer, for the reasons Alex explained....
The core of Kamailio is an RFC3261 SIP Server.
Adding or using different modules will to the list of RFCs... such as with CPL module (RFC3880), invoking P-asserted-identity (RFC3325), using DNS NAPTR (RFC2915), Websockets (RFC6455), etc.
I assume that what's actually going on here is that someone's boss/management/client/stakeholder made the arbitrary requirement, however nonsensical it is to us engineers, to list the RFCs supported and compare them that way.
In that case, a political solution is required, not a technically accurate one. And the political solution is to list as many pertinent RFCs as possible. This is useful:
https://datatracker.ietf.org/doc/rfc5411/?include_text=1
I encourage you to look at the title of that RFC and ponder why it exists, and consider my answer in that light. It wasn't meant to be hostile or standoffish. It's just the reality.
-- Alex
On 07/17/2014 04:06 PM, Alex Balashov wrote:
On 07/17/2014 03:53 PM, Fred Posner wrote:
The question is very difficult to answer, for the reasons Alex explained....
The core of Kamailio is an RFC3261 SIP Server.
Adding or using different modules will to the list of RFCs... such as with CPL module (RFC3880), invoking P-asserted-identity (RFC3325), using DNS NAPTR (RFC2915), Websockets (RFC6455), etc.
I assume that what's actually going on here is that someone's boss/management/client/stakeholder made the arbitrary requirement, however nonsensical it is to us engineers, to list the RFCs supported and compare them that way.
In that case, a political solution is required, not a technically accurate one. And the political solution is to list as many pertinent RFCs as possible. This is useful:
https://datatracker.ietf.org/doc/rfc5411/?include_text=1
I encourage you to look at the title of that RFC and ponder why it exists, and consider my answer in that light. It wasn't meant to be hostile or standoffish. It's just the reality.
-- Alex
I do want to write a module to make Kamailio RFC 2324 compliant, but am waiting for the proper hardware.
https://datatracker.ietf.org/doc/rfc2324/?include_text=1
--fred
Might worth starting a wiki page and try to collect what we support. But it is not trivial to identify which are full or partial supported and which were amended by newer rfcs and on what extent.
Have in mind that kamailio is a framework and it is a matter of config file to support or not some rfcs. Some of them are implemented in one or a group of modules (e.g., authentication, cpl, simple extensions, msrp, xcap), but some can be just a matter of scripting in config file (e.g, P-Asserted-Identity/P-Preferred-Identity handling).
There might be some list (google search?!?) of rfcs related to sip that can be imported in our wiki, then start to look at it and add note if it is supported. If anyone is starting such page on our wiki (http://www.kamailio.org/wiki/), I will contribute based on what I am aware. It can be a table with the RFCs (linked to their specs at ietf) in one column, and few extra columns like supported (e.g., full or partial) and how (e.g., by module, scripting, etc)
For an immediate list, one can grep the sources for RFC and search on kamailio.org site, many of them are mentioned, but the results will not be complete.
Cheers, Daniel
On 17/07/14 17:05, Conners, James wrote:
I found a partial list of supported RFCs on the website. What is the entire list of supported RFCs?
This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
Thanks Daniel,
Maybe it would be easier to answer my question if I asked whether the Kamailio SIP Server framework supports, partially or fully, the following RFCs when configured/scripted properly?
RFC No/Partial/Full ---- --------------- 3262 3311 3515 3581 3891 3966 4028
The Kamailio website indicates 3262 and 3581 are supported. Not wanting to assume this means full support, I listed them above for feedback. If support for any of these is only possible through scripting that would be helpful as well.
While I'm at it I might as well ask if there is any support for draft-ietf-cuss-sip-uui? Again, if support for this is only possible through scripting that would be good to know.
Thanks, Jim
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Thursday, July 17, 2014 4:45 PM To: Kamailio (SER) - Development Mailing List; Conners, James Subject: Re: [sr-dev] Supported RFCs
Might worth starting a wiki page and try to collect what we support. But it is not trivial to identify which are full or partial supported and which were amended by newer rfcs and on what extent.
Have in mind that kamailio is a framework and it is a matter of config file to support or not some rfcs. Some of them are implemented in one or a group of modules (e.g., authentication, cpl, simple extensions, msrp, xcap), but some can be just a matter of scripting in config file (e.g, P-Asserted-Identity/P-Preferred-Identity handling).
There might be some list (google search?!?) of rfcs related to sip that can be imported in our wiki, then start to look at it and add note if it is supported. If anyone is starting such page on our wiki (http://www.kamailio.org/wiki/), I will contribute based on what I am aware. It can be a table with the RFCs (linked to their specs at ietf) in one column, and few extra columns like supported (e.g., full or partial) and how (e.g., by module, scripting, etc)
For an immediate list, one can grep the sources for RFC and search on kamailio.org site, many of them are mentioned, but the results will not be complete.
Cheers, Daniel On 17/07/14 17:05, Conners, James wrote: I found a partial list of supported RFCs on the website. What is the entire list of supported RFCs? This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.
-
Alex Balashov -
Conners, James -
Daniel-Constantin Mierla -
Fred Posner