[sr-dev] Headers for IMS Extensions

[Jason Penton]

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 at gmail.com>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 at 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 at 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 at lists.sip-router.org
>> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>> >
>> >
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
>
> _______________________________________________
> sr-dev mailing listsr-dev at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20111103/6ded1aaf/attachment.htm>