On 10/5/15 7:23 PM, Maxim Sobolev 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.
This is also my interpretation.
I know of implementations that parse the parameters of a sip header
field and put them into a hash map. Then they can be serialized again,
but the order in which they were parsed will not be preserved. (This
would be what would happen when creating a response.) In my
understanding this is a valid implementation of the spec.
Thanks,
Paul
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
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
