|
From: | Aymeric Moizard |
Subject: | Re: Parsing diversion headers with osip |
Date: | Thu, 8 Jun 2023 15:35:06 +0200 |
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
Diversion headers are sometimes used for call forwarding to voice mail and things like that.
It is in essence a uri with optional params, like to, from, contact objects, etc. Since contact seems the closest type, I currently try breaking it down into a osip_contact_t, which really is just a set of macros for underlying osip “generic” uri/param parsing functions. My question is, should I really do that, should I call the underlying generic functions, or should I try creating osip_divert… macros and an osip_divert_t?
osip_header_t *divert{nullptr};
osip_message_header_get_byname(request, “Diversion”, 0, &divert);
if(divert && divert->hvalue) {
osip_contact_t *fwd{nullptr};
osip_contact_init(&fwd);
osip_contact_parse(fwd, divert->hvalue);
if(fwd->displayname)
leg->make_const({{"DIVERT_ID", fwd->displayname}});
if(fwd->url && fwd->url->username)
leg->make_const({{"DIVERT_FROM", fwd->url->username}});
osip_uri_param_t *reason{nullptr};
osip_contact_param_get_byname(fwd, const_cast<char *>("reason"), &reason);
if(reason && reason->gvalue)
leg->make_const({{"DIVERT_REASON", reason->gvalue}});
osip_uri_param_t *privacy{nullptr};
osip_contact_param_get_byname(fwd, const_cast<char *>("privacy"), &reason);
if(privacy && privacy->gvalue)
leg->make_const({{"DIVERT_PRIVACY", privacy->gvalue}});
…
[Prev in Thread] | Current Thread | [Next in Thread] |