Hi,
When working on the outbound support I noticed that this Contact header (as per RFC 5626):
Contact: sip:foo@192.168.1.18:5061;reg-id=1;+sip.instance="urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF"
does not get parsed properly (specifically, the param_hooks_t.hooks.reg_id is not filled in by parse_params()).
However, some investigation showed that:
Contact: <sip:foo@192.168.1.18:5061;reg-id=1;+sip.instance="urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF">
It looks like Kamailio is treating reg-id (and probably +sip.instance) parameters as Contact-URI parameters instead of Contact header parameters.
Regards,
Peter
peter,
i just tested and at least when reg-id and +sip.instance are in contact header
Contact: sip:0x82a0798@192.98.102.10:5052;transport=tcp;expires=600;+sip.instance="urn:uuid:447ff092-6236-47d9-bc0a-a3c6856aacf2";q=0.8;reg-id=1.
of register request, they do get parsed correctly, because they show up in instance and reg_id fields of location table.
-- juha
Hi Juha,
It must be something silly that I am doing then, but I can't see what. This code fragment:
if (msg->contact || parse_headers(msg, HDR_CONTACT_F, 0) != -1) { if (parse_contact(msg->contact) < 0) { LM_ERR("parsing Contact: header body\n"); return 0; } contact = ((contact_body_t *) msg->contact->parsed)->contacts; if (!contact) { LM_ERR("empty Contact:\n"); return 0; } if (parse_uri(contact->uri.s, contact->uri.len, &puri) < 0) { LM_ERR("parsing Contact-URI\n"); return 0; } if (parse_params(&puri.params, CLASS_CONTACT, &hooks, ¶ms) != 0) { LM_ERR("parsing Contact-URI parameters\n"); return 0; }
if (msg->REQ_METHOD == METHOD_REGISTER && hooks.contact.reg_id) { LM_INFO("found REGISTER with ;reg-id paramter on" "Contact-URI - outbound used\n"); return 1; }
Prints out the last diagnostic when reg-id is a Contact-URI parameter, but not a Contact: header parameter.
I've no idea why, but this is obviously not right. Any ideas?
Peter
peter,
i just tested and at least when reg-id and +sip.instance are in contact header
Contact: sip:0x82a0798@192.98.102.10:5052;transport=tcp;expires=600;+sip.instance="urn:uuid:447ff092-6236-47d9-bc0a-a3c6856aacf2";q=0.8;reg-id=1.
of register request, they do get parsed correctly, because they show up in instance and reg_id fields of location table.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
On 1/2/13 12:15 PM, Peter Dunkley wrote:
Hi Juha,
It must be something silly that I am doing then, but I can't see what. This code fragment:
if (msg->contact || parse_headers(msg, HDR_CONTACT_F, 0) != -1) { if (parse_contact(msg->contact) < 0) { LM_ERR("parsing Contact: header body\n"); return 0; } contact = ((contact_body_t *)
msg->contact->parsed)->contacts; if (!contact) { LM_ERR("empty Contact:\n"); return 0; } if (parse_uri(contact->uri.s, contact->uri.len, &puri) < 0) { LM_ERR("parsing Contact-URI\n"); return 0; } if (parse_params(&puri.params, CLASS_CONTACT, &hooks, ¶ms) != 0) { LM_ERR("parsing Contact-URI parameters\n"); return 0; }
above you parse the Contact URI parameters, not the contact header parameters. That's why you don't get the reg-id, because is a header parameter.
The parse_contact() parses the header parameters and makes them available in (contact_t*)->params, with some hooks in special fields for most used parameters, see parser/contact/contact.h for the structure. It is no need parse additionally the contact header parameters.
Cheers, Daniel
if (msg->REQ_METHOD == METHOD_REGISTER &&
hooks.contact.reg_id) { LM_INFO("found REGISTER with ;reg-id paramter on" "Contact-URI - outbound used\n"); return 1; }
Prints out the last diagnostic when reg-id is a Contact-URI parameter, but not a Contact: header parameter.
I've no idea why, but this is obviously not right. Any ideas?
Peter
peter,
i just tested and at least when reg-id and +sip.instance are in contact header
Contact: sip:0x82a0798@192.98.102.10:5052;transport=tcp;expires=600;+sip.instance="urn:uuid:447ff092-6236-47d9-bc0a-a3c6856aacf2";q=0.8;reg-id=1.
of register request, they do get parsed correctly, because they show up in instance and reg_id fields of location table.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev