Re: [sipcore] 4244bis -- some examples

["Worley, Dale R (Dale)" <[e-mail]>]

Some talking points regarding the recent examples:

1. It's not clear why the "rc" parameter does not have a value telling
where the hi-targeted-uri is derived from, but the "mp" parameter does.
(This is ticket 41.)

2. For hi-entry's that do not have either "rc" or "mp", there is no
way to record where the hi-targeted-uri is derived from.  It would
seem desirable to move the mp-param to another parameter name that is
independent of "rc" and "mp", or to define an "other" parameter to use
in exactly the cases where "rc" and "mp" do not apply.

3. The "hit" URI-parameter on the Contact URIs in a 3xx response would
seem to be better done as header parameters.  This gives:

        Contact: <sip:A>;hit=rc, <sip:B>;hit=mp, <sip:C>

(This is, or is related to, ticket 4.)

4. As far as I can tell from the rules, the intention is that
History-Info will contain sibling forks of the current request only if
the sibling fork has already returned a response.  There doesn't seem
to be a strong reason not to always include all sibling forks,
although if we retain the convention that the last hi-entry
corresponds to the containing request, we can't always document all
known sibling forks in History-Request (as some of them will have
higher index numbers than the containing request).

5. The response to a request is encoded in a Reason 'header' in the
hi-targeted-uri.  It would seem more natural to encode the value in a
header parameter.  E.g.:

        History-Info: hhh,
                      <sip:R>;index=xxx.1;reason=SIP%3bcause%3d302,
                      <sip:A>;index=xxx.2;rc

6. In the fourth example, when the call falls over to voicemail
(sip:C), the History-Info shows the derivation of the request-URI (if
change 2 above is accepted):

        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:A?Reason=SIP%3bcause%3d487>;index=xxx.2;rc,
                      <sip:B?Reason=SIP%3bcause%3d487>;index=xxx.3;mp=xxx.1,
                      <sip:C>;index=xxx.4;other=xxx.1

But it does not explicitly show which failed forks caused the fork to
sip:C to be generated.  (In this case, the call falls back to
voicemail only after forks xxx.2 and xxx.3 do not answer.)  It may be
possible to deduce this information in many cases, but to solve the
problem in all cases will probably require making this information
explicit.  E.g.,

        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:A?Reason=SIP%3bcause%3d487>;index=xxx.2;rc=xxx.1,
                      <sip:B?Reason=SIP%3bcause%3d487>;index=xxx.3;mp=xxx.1,
                      <sip:C>;index=xxx.4;other=xxx.1;after=xxx.2/xxx.3

The "after" parameter specifies the request(s) whose responses caused
the sip:C fork to be generated.  (I did not add "after" to xxx.2 and
xxx.3 because the values of the rc and mp parameters make those
dependencies explicit.)

Dale