|
From: | David Sugar |
Subject: | Re: Parsing diversion headers with osip |
Date: | Thu, 8 Jun 2023 10:35:09 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 |
It’s probably not used much outside of
carriers, like for IMS, so I don’t
think we need to have an explicit osip_divert_t, especially given
you haven't had anyone else ask about it before in all these
years, and osip_from_t can be pressed into service....
Hello again David,
I'm a little confused about rfc5806 and the next rfc6044.
The example are confusing related to usage of < and > characters. In the rfcthey seems to indication no usage of name-addr, but the syntax definition requires it.
I end up reading this discussion where it is said that the rfc are historic and informationaland vendor may implement the way they want....
Sorry, but Diversion may need to be done per vendor to interoperate!Still, using the osip_from_t is the correct way!
RegardsAymeric
Le jeu. 8 juin 2023 à 15:35, Aymeric Moizard <amoizard@gmail.com> a écrit :
Hi David,
Good to hear from you!
Instead of using osip_contact_t, I advise to use osip_from_t. They are very close, but the "Contact" header can have a special value which is the STAR character.
I searched for the definition of Diversion and I can see it was first defined in rfc5806. Later it was redefined in a proper way (using ABNF, as in rfc3261)
The big difference is the following:1/ From header can have a name-addr OR addr-spec2/ Diversion can only have a name-addr
Here is the definition of name-addr:
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
This means that the diversion sip address must always be inside < and > characters.
I've read my code and I think osip_from_to_str API is always using the name-addr formeven when it's not required. So it should be 100% compatible with the Diversion header.
The only mistake would be to accept Diversion with non standard format.
Best Regards!Aymeric
Le jeu. 8 juin 2023 à 12:58, David Sugar <tychosoft@gmail.com> a écrit :
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] |