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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
