Resubmitted Requests that might not Merge (Was: [Sip] comments on sip-auth)

["Jo Hornsby" <jhornsby@ubiquity.net>]

> Section 7.3 says:
>    If a stateful proxy receives a 492 and determines that it contains a
>    single UAS-Authenticate header targeted solely at itself, it MAY
>    resubmit the request to the UAS with a UAS-Authorization header
>    containing the credential as a separate branch.
> 
> I don't think this is possible because the Cseq number must
> be increased (otherwise it will look like a re-transmission
> or merged request) and the proxy does not own the CSeq. It
> would have to be a B2BUA and generate its own Cseq (and
> possibly Call-Id).

Actually, I think this may be fine.  Section 8.2.2.2 of
RFC3261^H^H^H^H^H^H^Hbis-09 only puts a SHOULD strength
on a 482, and thus I see no reason for clever UAs to
not look out for resubmitted requests (i.e., those that
are only different based on the topmost-Via), such that
they can attempt to resatisfy the request based on
the condition that the previous N-instances of this
request were all treated to a non-2xx final.

I thought that there had been some mention of this in
Session Timer (because there are cases where a UAS
can receive a request N times; along (N - 1) paths the
refresh interval is too small, but along one path,
it is acceptable; if the acceptable path "arrives"
last, not treating it as a merge avoids RTTs in
negotiation, which may not even occur if UPDATE is
not supported).  But a quick skim failed to turn
anything up.  However, there was definitely a mailing-
list thread that ultimately produced the new merge
behaviour.

Furthermore, a similar approach is suggested in
update-01 Section 7, when a proxy does the
Require:update thing.  Now, I expect this to become
less common, based on the proposed resolution of
a UAS sending a 155 being SHOULD; however, it
does seem to me that it would be a shame to rule
it out, since I can see very little that's -ve
about it beyond a slight bit of extra logic in
the "UAS core".


 - Jo.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip