If it had started "The Via headers in the response..." then I would agree with you.
But it starts "The Via header field values in the response" so I interpret that to mean the order of the values within each individual Via header. I believe the order of the Via headers is dealt with in a different part of the RFC which describes when and where Via headers are added. On 6 October 2015 at 10:23, Maxim Sobolev <sobo...@sippysoft.com> wrote: > David, IMHO that "same ordering" clause refers to the "header values" > (i.e. individual "via" lines), not to the order of parameters within ONE > header value. Order of values is important, because it defines your return > path. Which is why the clause is there, I believe. Order of parameters on > the other hand has no particular meaning. > > On Mon, Oct 5, 2015 at 4:18 PM, David Cunningham < > dcunning...@voisonics.com> wrote: > >> Hi Maxim, >> >> Surely it says in the text you've quoted "and MUST maintain the same >> ordering"? >> >> >> On 6 October 2015 at 10:10, Maxim Sobolev <sobo...@sippysoft.com> wrote: >> >>> Sorry, I've obviously put colon instead of semi-colon in my example, the >>> correct one should read: >>> >>> SIP/2.0/UDP 1.2.3.4;foo=bar;bar=baz >>> >>> vs. >>> >>> SIP/2.0/UDP 1.2.3.4;bar=baz;foo=bar >>> >>> >>> On Mon, Oct 5, 2015 at 4:06 PM, Maxim Sobolev <sobo...@sippysoft.com> >>> wrote: >>> >>> > Hi everybody, >>> > >>> > We came across a device that inserts some non-standard parameter into >>> one >>> > of the Via headers of request and has an issue dealing with situation >>> when >>> > this parameter is moved by our UAS to a different position of that >>> > particular Via header in the response. Therefore, my question is: are >>> we >>> > actually required to preserve order of parameters in each Via or not? >>> The >>> > RFC is not very clear on that matter, all it says is: >>> > >>> > 8.2.6.2 Headers and Tags >>> > >>> > [...] >>> > >>> > response MUST equal the CSeq field of the request. The Via header >>> > field values in the response MUST equal the Via header field values >>> > in the request and MUST maintain the same ordering. >>> > >>> > To me, this boils down to the question of what we call "equal" field >>> values, can the field values below be considered equal: >>> > >>> > SIP/2.0/UDP 1.2.3.4:foo=bar;bar=baz >>> > >>> > vs. >>> > >>> > SIP/2.0/UDP 1.2.3.4:bar=baz;foo=bar >>> > >>> > Speaking from experience, it's probably bad idea to bet on UAS keeping >>> order the same when developing your own UAC code, but if somebody decides >>> to do it, can they claim that you are violating RFC if you don't? >>> > >>> > Thanks! >>> > >>> > -Maxim >>> > >>> > >>> >>> >>> -- >>> Maksym Sobolyev >>> Sippy Software, Inc. >>> Internet Telephony (VoIP) Experts >>> Tel (Canada): +1-778-783-0474 >>> Tel (Toll-Free): +1-855-747-7779 >>> Fax: +1-866-857-6942 >>> Web: http://www.sippysoft.com >>> MSN: sa...@sippysoft.com >>> Skype: SippySoft >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> >> >> >> >> -- >> David Cunningham, Voisonics >> http://voisonics.com/ >> USA: +1 213 221 1092 >> UK: +44 (0) 20 3298 1642 >> Australia: +61 (0) 2 8063 9019 >> > > > > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > Tel (Canada): +1-778-783-0474 > Tel (Toll-Free): +1-855-747-7779 > Fax: +1-866-857-6942 > Web: http://www.sippysoft.com > MSN: sa...@sippysoft.com > Skype: SippySoft > -- David Cunningham, Voisonics http://voisonics.com/ USA: +1 213 221 1092 UK: +44 (0) 20 3298 1642 Australia: +61 (0) 2 8063 9019 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors