arjun>>> I have worked with people on the embedded side who simply
arjun>>> cannot allocate
arjun>>> more than Xk for SIP messages and
arjun>>> by policy, their application rejects any message greater than
this, by
arjun>>> returning a message too long bad response( I think its a
arjun>>> 413). While this
arjun>>> may not be desirable, at times it can be a practical limitation.
jdr>> Well, I would encourage them to set X to at least 2 or 3 for now. SIP
jdr>> messages are getting bigger all the time.
jdr>> In any case, that is different from the arbitrary limit imposed on a
jdr>> particular header. In this case, requests were being rejected (or
causing
jdr>> the system to crash or something) even though the total length was
within
jdr>> reasonable bounds.
Agree here. As I mentioned in a prev. mail, per header limits is imho,
unjustified.
Per message, well, that you can't do without in many cases.
>
arjun>>> If the UA crashes, I would say its certainly a no-no. If it
arjun>>> declines by
arjun>>> saying 'sorry, I can't handle your message', then its certainly
arjun>>> a scenario that should be still in line. I would say that
arjun>>> this approach is
arjun>>>> still inter-operable .
jdr>> Not really. Interoperability means that communications is
successfully set
jdr>> up. It has not been here.
Actually yes - however if a client does not accept a message > Xk,it is
still SIP compliant.
As long as it can move back to a steady state giving the other side a valid
protocol message saying why it failed.
I think 'compliant to SIP' would have been a more appropriate term for me
to use, rather than 'interoperable'. In this case its just the client
policy to say msg>X is a reject.
(Note that I am not talking about this specific case of that vendor's
client barfing )
Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems
