-----Message d'origine----- De : MOHALI Marianne RD-CORE [mailto:[email protected]] Envoyé : mercredi 4 avril 2012 15:21 À : Brandon W. Yuille; [email protected] Cc : CHATRAS Bruno RD-CORE-ISS Objet : RE: [Sip-implementors] TR: BroadSoft's use of Diversion Header
Yes sorry, I wrote my message to fast. Actually, the ";" has been replaced by a SEMI but it is in the second line of the syntax in RFC6044. Indeed, I think that the confusion comes from that there is no COMMA (or ",") in the RFC5806 syntax. So, I agree with you that RFC5806 is more header-separated. My point is: - RFC5806 is header-separated based but the syntax contains mistakes and from the beginning we observed both formats (comma-separated and header-separated) in implementations. - RFC6044 makes the syntax more generic to correspond to the real implementations using the RFC3261 principle that a header can be in both formats even mixed and should be read (for Diversion) from the bottom-right to the top-left either separated with COMMA or with header name. I know that it is an additional work to understand both formats but it was the only solution that fit with the real word. RFC5806 is Historic and RFC6044 is Informational so it relies on implementors ability to implement the both formats recognition or to implement the more common format (header-separated). Marianne -----Message d'origine----- De : Brandon W. Yuille [mailto:[email protected]] Envoyé : mercredi 4 avril 2012 12:17 À : [email protected] Cc : CHATRAS Bruno RD-CORE; MOHALI Marianne RD-CORE Objet : Re: [Sip-implementors] TR: BroadSoft's use of Diversion Header 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
