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(a)gmail.com>wrote;wrote:
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:
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(a)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/SI…
Cheers
Jason
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)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