Hello,
Inaki, I pinged you since you may be more familiar with procedures about all this IETF output, but maybe others here can provide useful information as well.
At this moment the parser in Kamailio for Diversion header considers it as with similar format as To header.
Diversion (defined in an *Historic* rfc5806) is obsoleted by History-Info(*Standard track* rfc4244). Its definition in rfc5806 is:
Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params ))
and it is like To header. However, a newer *Informational* rfc6044, redefines Diversion as:
Diversion = "Diversion" HCOLON diversion-params *(COMMA diversion-params)
diversion-params = name-addr *(SEMI (diversion-reason / diversion-counter / diversion-limit / diversion-privacy / diversion-screen / diversion-extension))
So in rfc6044, the sintax allow comma separated bodies for one Diversion header, which was not in rfc5806. Obviously, the current diversion parser throws error, so I guess it has to be updated to accept a format similar to Route headers.
My question is, apart of rfc number and the policy more recent (bigger values) obsoletes older (lower value) specification, does the Informational or Historic category to set some extra rules?
Btw, are people here still using (or ever used -- I didn't so far) Diversion?
Cheers, Daniel
On Tuesday 31 January 2012, Daniel-Constantin Mierla wrote:
[...] My question is, apart of rfc number and the policy more recent (bigger values) obsoletes older (lower value) specification, does the Informational or Historic category to set some extra rules?
Hi Daniel,
if I understand RFC 6044 correctly, its about the interworking between History-Info and Diversion. About the syntax changes I can't comment at the moment.
Btw, are people here still using (or ever used -- I didn't so far) Diversion?
Yes, we're using it a lot at the moment. AFAIK one of the reasons that the IETF published Diversion as a history RFC was to admit that even after seven years since the publishing of RFC 4244 people keep using the Diversion header. Probably because its just simpler for the common use case - preventing call forwarding loops in VoIP signalization and PSTN interconnection and many existing equipment out there supports it.
Best regards,
Henning
On 31.01.2012 12:38, Daniel-Constantin Mierla wrote:
Btw, are people here still using (or ever used -- I didn't so far) Diversion?
We use it for our did-provider (Uninett, national NREN). By default the caller will see the number specified by: P-Asserted-Identity: sip:+4700000000 If we either have a call which is call forwarded or we want to hide the callee's number, we can put a different number in the Diversion field and then that number will be set as callee. P-Asserted-Identity is then used for billing only.