> From: harbhanu sahai [[email protected]] > > How about defining a new 4xx* '*Session Interval Too Large' response code > with similar semantics such as 422 ? > > We have seen that at times UA cannot upfront put the *correct* MinSE value > based on corresponding values at downstream proxies. I believe similar > rationale is used while defining 422 response code. > This can result is successful session establishment in cases where UAC > can accommodate this change.
I am not an expert on session-timers. I believe that a specific error message would be helpful, but only for diagnostic use. The critical semantics of a 422 response is that the proposed Session-Expires value is too small (in the opinion of some proxy on the path), and that the UA should retry with a larger Session-Expires value. It is not stated clearly in the RFC, but it appears that the various proxies' Min-SE values are expected to be *absolute* but the Session-Expires value is expected to be *advisory* -- a proxy has no authority to accept a Session-Expires value that is less than its Min-SE, but the UA can always be made to propose a Session-Expires value that is larger than *any* Min-SE value that it receives. Although proxies are allowed to reduce the Session-Expires value (RFC 4028 section 8.1), it seems to me that the protocol expects that they will not generally choose to do so. Within this set of expectations, a 422 response is never "final", in that a UAC is expected to always retry the INVITE with Min-SE copied from the 422 and Session-Expires some value greater than or equal to the Min-SE value. The case that you are interested in, where the *maximum* refresh interval acceptable to one proxy is less than the *minimum* refresh interval acceptable to another proxy, does not seem to be discussed in the RFC, or even conceptualized. Consider this text from section 8.1: If the value of the Session-Expires header field is lower than the value of the Min-SE header field (possibly because the proxy increased the value of the Min-SE header field, as described below), the proxy MUST increase the value of the Session-Expires header field to make it equal to Min-SE header field value. The Session-Expires value seen by previous proxies (and possibly reduced by them) can be *increased* by later proxies. There being no recovery from such a conflict, the only value of a special response is diagnostic. It might be useful to define a new error response (or perhaps a warning code (RFC 3261 section 27.2) to be added to a 403 response) to indicate that this proxy requires a certain maximum sesson timer interval. In practice, the problem in your situation (the proxy requiring Session-Expires to be exactly 1800) is that the protocol design and almost all implementations assume that every proxy will accept a wide range of expiration intervals, and the upper limit of the range will be very high. And it's clear that the practice of requiring a specific expiration interval is unlikely to interoperate successfully, as if there are two such proxies in the path but they have different required expiration intervals, no calls can pass through them. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
