Hi Daniel,<div><br>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.</div><div><br></div><div>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?</div>
<div><br></div><div>Cheers</div><div>Jason</div><div><br></div><div><br><div class="gmail_quote">On Wed, Nov 2, 2011 at 5:37 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
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. <br>
<br>
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).<br>
<br>
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.<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
On 11/2/11 4:31 PM, Jason Penton wrote:
</div></div><blockquote type="cite"><div><div class="h5">Hey Ovidiu
<div><br>
</div>
<div>
<div class="gmail_quote">On Wed, Nov 2, 2011 at 5:27 PM, Ovidiu
Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the headers must be accessible by several modules, then
it would<br>
make sense to have them into existing framework.<br>
One option would be to enable some compile flags and compile
that code<br>
only for IMS (similar to FLAVOUR - we could add a new
flavour)<br>
</blockquote>
<div><br>
</div>
<div>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......</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<span><font color="#888888">Ovidiu Sas<br>
</font></span>
<div>
<div><br>
On Wed, Nov 2, 2011 at 10:51 AM, Jason Penton <<a href="mailto:jason.penton@gmail.com" target="_blank">jason.penton@gmail.com</a>>
wrote:<br>
> Hi all,<br>
> I wanted to ask the community what the best way
forward is for incorporating<br>
> new SIP (IMS specific) headers into Kamailio. Right
now I see two ways:<br>
> 1. incorporating into existing parser framework in
Kamailio<br>
> 2. Leave it up to individual modules to
independently parse for appropriate<br>
> IMS headers.<br>
> I would think 1 would be the best option?<br>
> Here are some examples of the extension headers:<br>
> <a href="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" target="_blank">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</a><br>
> Cheers<br>
> Jason<br>
</div>
</div>
<div>
<div>>
_______________________________________________<br>
> sr-dev mailing list<br>
> <a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
><br>
><br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
<br>
</div></div><span class="HOEnZb"><font color="#888888"><pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Kamailio Advanced Training, Dec 5-8, Berlin: <a href="http://asipto.com/u/kat" target="_blank">http://asipto.com/u/kat</a>
<a href="http://linkedin.com/in/miconda" target="_blank">http://linkedin.com/in/miconda</a> -- <a href="http://twitter.com/miconda" target="_blank">http://twitter.com/miconda</a></pre>
</font></span></blockquote>
</div>
</blockquote></div><br></div>