2 nov 2011 kl. 15:51 skrev Jason Penton: incorporating new SIP (IMS specific) headers into Kamailio. Right now I see two ways: appropriate IMS headers. 3. Leave it to the configuration script to handle http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SI… 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(a)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(a)gmail.com> wrote: incorporating appropriate http://docs.redhat.com/docs/en-US/JBoss_Communications_Platform/5.0/html/SI… _______________________________________________ sr-dev mailing list sr-dev(a)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(a)voipembedded.com> wrote: 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...... _______________________________________________ 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: content, 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. sip 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

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(a)kamailio.org>wrote;wrote: _______________________________________________ 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