Hi all,
I wanted to ask the community what the best way forward is for incorporating new SIP (IMS specific) headers into Kamailio. Right now I see two ways:
1. incorporating into existing parser framework in Kamailio 2. Leave it up to individual modules to independently parse for appropriate IMS headers.
I would think 1 would be the best option?
Here are some examples of the extension headers: http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP...
Cheers Jason
2 nov 2011 kl. 15:51 skrev Jason Penton:
Hi all,
I wanted to ask the community what the best way forward is for incorporating new SIP (IMS specific) headers into Kamailio. Right now I see two ways:
- incorporating into existing parser framework in Kamailio
- Leave it up to individual modules to independently parse for appropriate IMS headers.
3. Leave it to the configuration script to handle
I would think 1 would be the best option?
Here are some examples of the extension headers: http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP...
The big question is really which of these that NEED logic in modules and not in the configuration script.
/O
Hey Olle
Trust you are well, its been a long time since the first Atricon many moons ago!
Well, the modules will be quite dependent on headers like asserted and preferred identities. For example, the IMS registrar module we are working on will need these header to do the IMS AKA (Authentication and Key Agreement)
On Wed, Nov 2, 2011 at 5:01 PM, Olle E. Johansson oej@edvina.net wrote:
2 nov 2011 kl. 15:51 skrev Jason Penton:
Hi all,
I wanted to ask the community what the best way forward is for
incorporating new SIP (IMS specific) headers into Kamailio. Right now I see two ways:
- incorporating into existing parser framework in Kamailio
- Leave it up to individual modules to independently parse for
appropriate IMS headers. 3. Leave it to the configuration script to handle
I would think 1 would be the best option?
Here are some examples of the extension headers:
http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP...
The big question is really which of these that NEED logic in modules and not in the configuration script.
/O
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
If the headers must be accessible by several modules, then it would make sense to have them into existing framework. One option would be to enable some compile flags and compile that code only for IMS (similar to FLAVOUR - we could add a new flavour)
Regards, Ovidiu Sas
On Wed, Nov 2, 2011 at 10:51 AM, Jason Penton jason.penton@gmail.com wrote:
Hi all, I wanted to ask the community what the best way forward is for incorporating new SIP (IMS specific) headers into Kamailio. Right now I see two ways:
- incorporating into existing parser framework in Kamailio
- Leave it up to individual modules to independently parse for appropriate
IMS headers. I would think 1 would be the best option? Here are some examples of the extension headers: http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP... Cheers Jason _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hey Ovidiu
On Wed, Nov 2, 2011 at 5:27 PM, Ovidiu Sas osas@voipembedded.com wrote:
If the headers must be accessible by several modules, then it would make sense to have them into existing framework. One option would be to enable some compile flags and compile that code only for IMS (similar to FLAVOUR - we could add a new flavour)
don't know if I would go so far as to call it another 'flavour' (semantically), but yes compile flags may be the way to go......
Regards, Ovidiu Sas
On Wed, Nov 2, 2011 at 10:51 AM, Jason Penton jason.penton@gmail.com wrote:
Hi all, I wanted to ask the community what the best way forward is for
incorporating
new SIP (IMS specific) headers into Kamailio. Right now I see two ways:
- incorporating into existing parser framework in Kamailio
- Leave it up to individual modules to independently parse for
appropriate
IMS headers. I would think 1 would be the best option? Here are some examples of the extension headers:
http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP...
Cheers Jason _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
do not forget that we have internal libraries, if you have code shared by several modules but it is not for general interest to be stored in core. It is better than using defines, IMO. Users take usually what is given by default, it is rarely when people compile with different flags and providing a feature that requires this will make testing harder and adoption slower.
For example, even now there are some parser extensions in lib/kcore/ (which I plan to move to core, btw, since there were left there by the integration process).
Just a clarification for myself, I guess you mean parsing the content of IMS specific headers, since there is a generic parser for any kind of header, that will give the header name and body.
Cheers, Daniel
On 11/2/11 4:31 PM, Jason Penton wrote:
Hey Ovidiu
On Wed, Nov 2, 2011 at 5:27 PM, Ovidiu Sas <osas@voipembedded.com mailto:osas@voipembedded.com> wrote:
If the headers must be accessible by several modules, then it would make sense to have them into existing framework. One option would be to enable some compile flags and compile that code only for IMS (similar to FLAVOUR - we could add a new flavour)don't know if I would go so far as to call it another 'flavour' (semantically), but yes compile flags may be the way to go......
Regards, Ovidiu Sas On Wed, Nov 2, 2011 at 10:51 AM, Jason Penton <jason.penton@gmail.com <mailto:jason.penton@gmail.com>> wrote: > Hi all, > I wanted to ask the community what the best way forward is for incorporating > new SIP (IMS specific) headers into Kamailio. Right now I see two ways: > 1. incorporating into existing parser framework in Kamailio > 2. Leave it up to individual modules to independently parse for appropriate > IMS headers. > I would think 1 would be the best option? > Here are some examples of the extension headers: > http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP_Servlets_Server_User_Guide/sect-SIP_and_IMS_Extensions.html#tab-IMS_P-Header_Extensions > Cheers > Jason > _______________________________________________ > sr-dev mailing list > sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel,
For Asserted and preferred identities, we don't need to parse the content, but in other headers I have not gotten to yet, we may need to.
Please help me understand, I would have thought from an architecture perspective, we would populate the sip_msg structure with all possible sip headers as well as the parsers. What is the reason we don't do this currently? performance?
Cheers Jason
On Wed, Nov 2, 2011 at 5:37 PM, Daniel-Constantin Mierla miconda@gmail.comwrote:
Hello,
do not forget that we have internal libraries, if you have code shared by several modules but it is not for general interest to be stored in core. It is better than using defines, IMO. Users take usually what is given by default, it is rarely when people compile with different flags and providing a feature that requires this will make testing harder and adoption slower.
For example, even now there are some parser extensions in lib/kcore/ (which I plan to move to core, btw, since there were left there by the integration process).
Just a clarification for myself, I guess you mean parsing the content of IMS specific headers, since there is a generic parser for any kind of header, that will give the header name and body.
Cheers, Daniel
On 11/2/11 4:31 PM, Jason Penton wrote:
Hey Ovidiu
On Wed, Nov 2, 2011 at 5:27 PM, Ovidiu Sas osas@voipembedded.com wrote:
If the headers must be accessible by several modules, then it would make sense to have them into existing framework. One option would be to enable some compile flags and compile that code only for IMS (similar to FLAVOUR - we could add a new flavour)
don't know if I would go so far as to call it another 'flavour' (semantically), but yes compile flags may be the way to go......
Regards, Ovidiu Sas
On Wed, Nov 2, 2011 at 10:51 AM, Jason Penton jason.penton@gmail.com wrote:
Hi all, I wanted to ask the community what the best way forward is for
incorporating
new SIP (IMS specific) headers into Kamailio. Right now I see two ways:
- incorporating into existing parser framework in Kamailio
- Leave it up to individual modules to independently parse for
appropriate
IMS headers. I would think 1 would be the best option? Here are some examples of the extension headers:
http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SIP...
Cheers Jason _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
On Thursday 03 November 2011, Jason Penton wrote:
For Asserted and preferred identities, we don't need to parse the content, but in other headers I have not gotten to yet, we may need to.
Hi Jason,
do you talk about p-asserted and p-preferred header? This are fairly standard headers, there are even some PVs to access them right now i think.
Please help me understand, I would have thought from an architecture perspective, we would populate the sip_msg structure with all possible sip headers as well as the parsers. What is the reason we don't do this currently? performance?
I'd guess the reasons is memory efficiency. The structure get bigger and bigger with every pointer. But for p-asserted and p-preffered, they are already included it seems:
struct hdr_field* pai; struct hdr_field* ppi;
Best regards,
Henning
Hey Henning,
Ahh, thanks for that, thats perfect for now!
A pity, those names should have been a little more descriptive ;)
Thanks Jason
On Thu, Nov 3, 2011 at 3:27 PM, Henning Westerholt hw@kamailio.org wrote:
On Thursday 03 November 2011, Jason Penton wrote:
For Asserted and preferred identities, we don't need to parse the
content,
but in other headers I have not gotten to yet, we may need to.
Hi Jason,
do you talk about p-asserted and p-preferred header? This are fairly standard headers, there are even some PVs to access them right now i think.
Please help me understand, I would have thought from an architecture perspective, we would populate the sip_msg structure with all possible
sip
headers as well as the parsers. What is the reason we don't do this currently? performance?
I'd guess the reasons is memory efficiency. The structure get bigger and bigger with every pointer. But for p-asserted and p-preffered, they are already included it seems:
struct hdr_field* pai; struct hdr_field* ppi;Best regards,
Henning
Hi Jason,
I'm just continuing on a topic discussed few messages back in this thread.
Actually it is recommended to avoid adding new direct header hooks in sip_msg_t structure, because it becomes too big compared with what actually a SIP message has in terms of headers. Apart of invite which can have between 10-20 headers in average, the rest have less number of headers. Note that all headers are linked in a list held in sip_msg_t->headers.
Getting a header from the list is possible with several functions, depending whether you want the first or next header, searched by internal ID (if that header has one) or simply by name. The prototypes for these functions are in parser/msg_parse.h:
hdr_field_t* get_hdr(sip_msg_t *msg, enum _hdr_types_t ht); hdr_field_t* next_sibling_hdr(hdr_field_t *hf); hdr_field_t* get_hdr_by_name(sip_msg_t *msg, char *name, int name_len); hdr_field_t* next_sibling_hdr_by_name(hdr_field_t *hf);
So getting my X-Header would be like:
parse_headers(msg, HDR_EOH_F, 0); hdr = get_hdr_by_name(msg, "X-Header", strlen("X-Header"));
Some of them may be even removed from sip_msg_t (like priority or subject) which are not common at all.
Cheers, Daniel
On 11/4/11 6:35 AM, Jason Penton wrote:
Hey Henning,
Ahh, thanks for that, thats perfect for now!
A pity, those names should have been a little more descriptive ;)
Thanks Jason
On Thu, Nov 3, 2011 at 3:27 PM, Henning Westerholt <hw@kamailio.org mailto:hw@kamailio.org> wrote:
On Thursday 03 November 2011, Jason Penton wrote: > For Asserted and preferred identities, we don't need to parse the content, > but in other headers I have not gotten to yet, we may need to. Hi Jason, do you talk about p-asserted and p-preferred header? This are fairly standard headers, there are even some PVs to access them right now i think. > Please help me understand, I would have thought from an architecture > perspective, we would populate the sip_msg structure with all possible sip > headers as well as the parsers. What is the reason we don't do this > currently? performance? I'd guess the reasons is memory efficiency. The structure get bigger and bigger with every pointer. But for p-asserted and p-preffered, they are already included it seems: struct hdr_field* pai; struct hdr_field* ppi; Best regards, Henning
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
OK Thanks Daniel.
I was initially thinking this was a cost of memory vs. CPU scenario, but actually on 2nd thoughts, the CPU cycles is the same. So effectively we use less memory by default and any code that requires extra headers can parse them on a need-to-have basis.
Thanks for clearing up
Cheers Jason
On Fri, Nov 4, 2011 at 10:49 AM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hi Jason,
I'm just continuing on a topic discussed few messages back in this thread.
Actually it is recommended to avoid adding new direct header hooks in sip_msg_t structure, because it becomes too big compared with what actually a SIP message has in terms of headers. Apart of invite which can have between 10-20 headers in average, the rest have less number of headers. Note that all headers are linked in a list held in sip_msg_t->headers.
Getting a header from the list is possible with several functions, depending whether you want the first or next header, searched by internal ID (if that header has one) or simply by name. The prototypes for these functions are in parser/msg_parse.h:
hdr_field_t* get_hdr(sip_msg_t *msg, enum _hdr_types_t ht); hdr_field_t* next_sibling_hdr(hdr_field_t *hf); hdr_field_t* get_hdr_by_name(sip_msg_t *msg, char *name, int name_len); hdr_field_t* next_sibling_hdr_by_name(hdr_field_t *hf);
So getting my X-Header would be like:
parse_headers(msg, HDR_EOH_F, 0); hdr = get_hdr_by_name(msg, "X-Header", strlen("X-Header"));
Some of them may be even removed from sip_msg_t (like priority or subject) which are not common at all.
Cheers, Daniel
On 11/4/11 6:35 AM, Jason Penton wrote:
Hey Henning,
Ahh, thanks for that, thats perfect for now!
A pity, those names should have been a little more descriptive ;)
Thanks Jason
On Thu, Nov 3, 2011 at 3:27 PM, Henning Westerholt hw@kamailio.orgwrote:
On Thursday 03 November 2011, Jason Penton wrote:
For Asserted and preferred identities, we don't need to parse the
content,
but in other headers I have not gotten to yet, we may need to.
Hi Jason,
do you talk about p-asserted and p-preferred header? This are fairly standard headers, there are even some PVs to access them right now i think.
Please help me understand, I would have thought from an architecture perspective, we would populate the sip_msg structure with all possible
sip
headers as well as the parsers. What is the reason we don't do this currently? performance?
I'd guess the reasons is memory efficiency. The structure get bigger and bigger with every pointer. But for p-asserted and p-preffered, they are already included it seems:
struct hdr_field* pai; struct hdr_field* ppi;Best regards,
Henning
sr-dev mailing listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
-
Daniel-Constantin Mierla -
Henning Westerholt -
Jason Penton -
Olle E. Johansson -
Ovidiu Sas