osip-dev
[Top][All Lists]
Advanced

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

https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-April/028270.html

Sorry, but Diversion may need to be done per vendor to interoperate!
Still, using the osip_from_t is the correct way!

Regards
Aymeric


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



--


--
Antisip - http://www.antisip.com

reply via email to

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