JR writes:
> Well, it will do one of two things:
>
> 1. its forgiving, as A is, and accepts the request
> 2. its strict, and rejects the request
>
> In the case of (1), the request will succeed, and thus A did the right
> thing by not rejecting it. In the case of (2), the end result is the
> same as if A had rejected the request. So, by passing the requests on
> even if they are not perfect, we improve the overall system
> robustness,
> since we have increased the chances of a successful request
> at no cost.
>
> I think being forgiving regarding syntax (and protocol semantics, too)
> is absolutely essential for real interoperability. The simple fact is
> that it is humans that are, in the end, implementing these protocols,
> with the invariable result of some amount of variability in what is
> being done. Being forgiving wherever possible helps us handle
> the "human factor" better.
SIP applications are not implemented by ordinary users.
SIP developers should be capable of reading the spec and writing the
software according to �t.
If we allow invalid SIP messages passed through, this encourages the
existence of broken SIP implementations (no need to fix them). This would
easily lead to H.323 like quasi-interoperability in which everything is
allowed (just agree with Microsoft what their implementation actually
understands so you can use Microsoft version of SIP instead of standard
SIP).
For Date and other informative headers this forgiving feature might make
sense not to verify them but where do we end ? Is SIP URL verified ? SDP m
attribute ? Loop-detection (which is a MUST in spec) ?
Somebody said that proxies are not supposed to be syntax police; they're
supposed to proxy messages.
Doesn't this mean that these kind of boxes are not SIP proxies at all,
rather they are packet forwarders (making simple editing like adding Via
header) ?
For proxies it is easier to verify messages and send detailed error codes.
Adam writes:
>though the Request-URI was a sip: URL. The consequence was
>that I couldn't even call my own (tel: aware) client with
>itself through these proxies.
>
>THIS IS BROKEN BEHAVIOR.
Yes, the proxy is broken and should be fixed.
It does not parse URI right (according to the URI spec RFC2396 which is
referenced in SIP spec)
URI can be almost anything.
The solution is to fix broken applications, rather than accept the incorrect
behaviour.
That's why we need bakeoffs etc.
--
Petri Koskelainen
Nokia
