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

Reply via email to