[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parsing diversion headers with osip

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....

On 6/8/23 09:45, Aymeric Moizard wrote:
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 rfc
they 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 informational
and 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!


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-spec
2/ 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 form
even 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!

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_parse(fwd, divert->hvalue);


            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}});   


Antisip - http://www.antisip.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]