Hi Peter,
One followup that may change everything I said about Broadsoft being
wrong: rfc 6044.
Looks like this informational rfc addressed the odd syntax you found in
rfc 5806:
3.2. Diversion Header Syntax
The following text is restating the exact syntax that the production
rules in [RFC5806 <http://tools.ietf.org/html/rfc5806>] define, but using
[RFC5234 <http://tools.ietf.org/html/rfc5234>] ABNF:
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))
diversion-reason = "reason" EQUAL ("unknown" / "user-busy" /
"no-answer" / "unavailable" / "unconditional"
/ "time-of-day" / "do-not-disturb" /
"deflection" / "follow-me" / "out-of-service"
/ "away" / token / quoted-string)
diversion-counter = "counter" EQUAL 1*2DIGIT
diversion-limit = "limit" EQUAL 1*2DIGIT
diversion-privacy = "privacy" EQUAL ("full" / "name" / "uri" /
"off" / token / quoted-string)
diversion-screen = "screen" EQUAL ("yes" / "no" / token /
quoted-string)
diversion-extension = token [EQUAL (token / quoted-string)]
Note: The Diversion header could be used in the comma-separated
format, as described below, and in a header-separated format. Both
formats could be combined a received INVITE as recommended in
[RFC3261 <http://tools.ietf.org/html/rfc3261>].
Example:
Diversion:
diverting_user2_addr; reason="user-busy"; counter=1; privacy=full,
diverting_user1_addr; reason="unconditional"; counter=1; privacy=off
So is Broadsoft correctly following the syntax in rfc 5806? No. Are they
correctly following the current syntax in informational rfc 6044? Yes.
However in my view: in order to be interoperable with devices supporting
the earlier rfc 5806 draft using the comma separated headers should be
discouraged. It's also odd to me that this section 3.2 claims "the
following text is restating the EXACT syntax that the production rules
in [RFC5806] define, but using [RFC5234] ABNF." I don't see how changing
the syntax to allow comma separated headers could be called exact.
Perhaps someone else who's more familiar with this rfc could shed light
on this apparent discrepancy.
Again, I hope I could help,
Brandon
On 04/04/2012 03:16 AM, Brandon W. Yuille wrote:
> Hi Peter,
>
> You're correct that their implementation does not follow the syntax for
> rfc 5806. Though I'm not really sure how much scrutiny that draft received.
>
> Is it a real problem? Probably not as I'd be willing to bet most
> implementations used the same parsing routines for the Diversion header
> as they would for any other header that contains a name-addr, which all
> that I can think of that allow multiple header lines also allow
> combining into one single header line separated by commas. I would think
> a programmer was rather odd if they chose to write a new parsing routing
> for name-addr headers that only allowed exactly 1 name-addr per header line.
>
> If you're just concerned with pointing out the problem to Broadsoft,
> then yes you have a valid point as there may be an odd device out there
> that followed the header syntax exactly. This would lead to interop
> problems. If Broadsoft were smart about interop they'd just put each
> Diversion name-addr on a separate line to avoid any such problem. I'd
> imagine they were looking to save space though.
>
> I hope I could help,
> Brandon
>
> On 04/03/2012 10:43 PM, Peter Childs wrote:
>
>> I notice that our BroadSoft AS platform on a multiple diverted call sends
>> the following to a Network element, where it appears two Diversion are
>> concatenated into a single Diversion: header as follows.
>>
>> Diversion:"NodePhone"<sip:0261404yyy@203.x.x.x;user=phone>;privacy=full;reason=unconditional;counter=1,"NodePhone"<sip:0267111zzz@203.x.x.x;user=phone>;privacy=full;reason=unconditional;counter=1
>>
>> Most examples in for example draft-levy-sip-diversion/RFC5806 where multiple
>> diversions exist show multiple Headers, one for each diversion.
>>
>> I did notice that in RFC3261 7.3 Headers Fields the following
>>
>> <quote>
>> That applies to SIP as well, but the specific rule is different because of
>> the different grammars. Specifically, any SIP
>> header whose grammar is of the form
>>
>> header = "header-name" HCOLON header-value *(COMMA header-value)
>>
>> allows for combining header fields of the same name into a comma-separated
>> list.
>> </quote>
>>
>> I note whilst RFC4244 for History-Info has (4.1)
>>
>> History-Info = "History-Info" HCOLON
>> hi-entry *(COMMA hi-entry)
>>
>> That RFC5806 for Diversion has (4)
>>
>> Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params ))
>>
>> My question is does BroadSoft's use of combining multiple Diversions in a
>> single Diversion Header appear to follow RFC5806?
>>
>> Thanks for your consideration.
>>
>> Cheers,
>> Peter
>>
>> --
>> Peter Childs - Voice Engineer
>> Internode/Agile
>>
>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
