OK Thanks Daniel.<div><div><div><br></div><div>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.</div>
<div><br></div><div>Thanks for clearing up</div><div><br></div><div>Cheers</div><div>Jason<br><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 10:49 AM, Daniel-Constantin Mierla <span dir="ltr">&lt;<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>&gt;</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">
    Hi Jason,<br>
    <br>
    I&#39;m just continuing on a topic discussed few messages back in this
    thread.<br>
    <br>
    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-&gt;headers.<br>
    <br>
    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:<br>
    <br>
    hdr_field_t* get_hdr(sip_msg_t *msg, enum _hdr_types_t ht);<br>
    hdr_field_t* next_sibling_hdr(hdr_field_t *hf);<br>
    hdr_field_t* get_hdr_by_name(sip_msg_t *msg, char *name, int
    name_len);<br>
    hdr_field_t* next_sibling_hdr_by_name(hdr_field_t *hf);<br>
    <br>
    So getting my X-Header would be like:<br>
    <br>
    parse_headers(msg, HDR_EOH_F, 0);<br>
    hdr = get_hdr_by_name(msg, &quot;X-Header&quot;, strlen(&quot;X-Header&quot;));<br>
    <br>
    Some of them may be even removed from sip_msg_t (like priority or
    subject) which are not common at all.<br>
    <br>
    Cheers,<span class="HOEnZb"><font color="#888888"><br>
    Daniel</font></span><div><div class="h5"><br>
    <br>
    On 11/4/11 6:35 AM, Jason Penton wrote:
    </div></div><blockquote type="cite"><div><div class="h5">Hey Henning, 
      <div><br>
      </div>
      <div>Ahh, thanks for that, thats perfect for now!</div>
      <div><br>
      </div>
      <div>A pity, those names should have been a little more
        descriptive ;)</div>
      <div><br>
      </div>
      <div>Thanks</div>
      <div>Jason<br>
        <br>
        <div class="gmail_quote">On Thu, Nov 3, 2011 at 3:27 PM, Henning
          Westerholt <span dir="ltr">&lt;<a href="mailto:hw@kamailio.org" target="_blank">hw@kamailio.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>On Thursday 03 November 2011, Jason Penton
              wrote:<br>
              &gt; For Asserted and preferred identities, we don&#39;t need
              to parse the content,<br>
              &gt; but in other headers I have not gotten to yet, we may
              need to.<br>
              <br>
            </div>
            Hi Jason,<br>
            <br>
            do you talk about p-asserted and p-preferred header? This
            are fairly standard<br>
            headers, there are even some PVs to access them right now i
            think.<br>
            <div><br>
              &gt; Please help me understand, I would have thought from
              an architecture<br>
              &gt; perspective, we would populate the sip_msg structure
              with all possible sip<br>
              &gt; headers  as well as the parsers. What is the reason
              we don&#39;t do this<br>
              &gt; currently? performance?<br>
              <br>
            </div>
            I&#39;d guess the reasons is memory efficiency. The structure
            get bigger and<br>
            bigger with every pointer. But for p-asserted and
            p-preffered, they are<br>
            already included it seems:<br>
            <br>
                   struct hdr_field* pai;<br>
                   struct hdr_field* ppi;<br>
            <br>
            Best regards,<br>
            <span><font color="#888888"><br>
                Henning<br>
              </font></span></blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class="im"><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>
    </div></blockquote><div class="im">
    <br>
    <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>
  </div></div>

</blockquote></div><br></div></div></div>