Thank you for your help in this matter Marianne. I'm a bit confused when you say:
>HCOLON is cleaner than ":" >COMMA is cleaner than ";" >Reminder of the RFC5806 syntax: Diversion = "Diversion" ":" 1# (name-addr *( >";" diversion_params )) COMMA should represent "," rather than SEMI ";" right? I think the matter that is confusing is the Diversion header was not defined as: "Diversion" ":" 1# (name-addr *( ";" diversion_params )) *( "," (name-addr *( ";" diversion_params )) If there was a COMMA "," there in rfc 5806 I would have agreed that the syntax is the same. Am I at fault somewhere? Thanks again for your response on the matter, Brandon On 04/04/2012 05:38 AM, [email protected] wrote: > Sent on behalf of Marianne MOHALI (author of RFC6044) as she is not on this > mailing list. > BC > --- > > -----Message d'origine----- > De : MOHALI Marianne RD-CORE [mailto:[email protected]] > Envoyé : mercredi 4 avril 2012 11:32 > À : CHATRAS Bruno RD-CORE-ISS > Objet : TR: [Sip-implementors] BroadSoft's use of Diversion Header > > Hello, > > When published, RFC5806 could not be changed in its content as it was > published as "historic" and many implementations cope with draft-levy. > When RFC6044 was written, this comment was added because it has been observed > several kind of implementations (comma-separated or header-separated) that > were not able to interwork (at the begining). > > Actually, there is no inconsistency between RFC5806 and RFC6044 because even > if the comma-separated format is not used in RFC5806's examples, with the > syntax and RFC3261 we can deduce that both formats are correct. > RFC3261 states (as said before) that "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." > > The correction to the syntax in RFC6044, was not concerning the > comma-separated topic, it was about the 1# that does not exist and does not > mean anything! So it should not be deduced that ONLY the "header-separated" > format is defined in RFC5806. > Other changes were only to make the syntax more clear: > HCOLON is cleaner than ":" > COMMA is cleaner than ";" > Reminder of the RFC5806 syntax: Diversion = "Diversion" ":" 1# (name-addr *( > ";" diversion_params )) > > > I hope it helps. > Best Regards, > Marianne > > > -----Message d'origine----- > De : [email protected] > [mailto:[email protected]] De la part de Brandon > W. Yuille > Envoyé : mercredi 4 avril 2012 09:36 > À : [email protected] > Objet : Re: [Sip-implementors] BroadSoft's use of Diversion Header > > 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:[email protected];user=phone>;privacy=full;reason=unconditional;counter=1,"NodePhone"<sip:[email protected];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 >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >>> >>> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
