while writing rr_count function, i noticed that after calling
if (parse_headers(msg, HDR_EOH_F, 0) == -1) {
when then going trough the headers of list msg->record_route, that list contained also other than rr headers. so i need to test the header type like this:
header = msg->record_route; while (header) { if (header->type == HDR_RECORDROUTE_T) {
why is that, i.e., why does parse_headers add other that rr headers to msg->record_route list? i imagined that when all headers are parsed, each header is added only to its own list and nowhere else.
-- juha
On Nov 16, 2009 at 23:42, Juha Heinanen jh@tutpro.com wrote:
while writing rr_count function, i noticed that after calling
if (parse_headers(msg, HDR_EOH_F, 0) == -1) {
when then going trough the headers of list msg->record_route, that list contained also other than rr headers. so i need to test the header type like this:
header = msg->record_route; while (header) {
if (header->type == HDR_RECORDROUTE_T) {
why is that, i.e., why does parse_headers add other that rr headers to msg->record_route list? i imagined that when all headers are parsed, each header is added only to its own list and nowhere else.
msg->record_route is just a shortcut to the first rr header. The list of all the headers is in msg->headers.
Im most cases the performance and especially the memory impact of keeping different headers-of-the-same-type lists would be too big compared with the performance hit of just iterating through the list of all the headers.
As Daniel pointed out in an email some time ago, we are thinking of reducing the number of shortcut pointers that we keep right now in sip_msg. We will probably create some generic get_first_hdr(type) and maybe get_next_hdr(type, crt) functions and then we'll remove most of the header shortcuts from sip_msg.
Andrei