Subject: [sipcore] 4244bis -- some examples

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Oct 2010 13:07:54 -0400

Four typical cases of redirection, showing the resulting History-Info
entries in the generated requests, per
draft-ietf-sipcore-rfc4244bis-01.  The final case, which
combines features of the first three cases, is typical for the
sipXecs/SCS system.

Incoming request has header:  History-Info: hhh
The final hi-entry in hhh has hi-index "xxx".

Case 1:  Request is forwarded to 3 destinations.

Destinations are sip:A (rc), sip:B (mp), and sip:C.

Outgoing request to A:
        History-Info: hhh,
                      <sip:A>;index=xxx.1;rc
Outgoing request to B:
        History-Info: hhh,
                      <sip:B>;index=xxx.2;mp=xxx
Outgoing request to C:
        History-Info: hhh,
                      <sip:C>;index=xxx.3

Case 2:  Request is forwarded to 3 destinations due to 302 response from
         redirect server.

Redirect server is sip:R.

Outgoing request to redirect server:
        History-Info: hhh,
                      <sip:R>;index=xxx.1

Incoming response from redirect server:  [same]

Destinations in 302 are <sip:A;hit=rc>, <sip:B;hit=mp>, and <sip:C>.

Outgoing request to A:
        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:A>;index=xxx.2;rc
[%3b is ';'.  %3d is '='.]
Outgoing request to B:
        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:B>;index=xxx.3;mp=xxx.1
Outgoing request to C:
        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:C>;index=xxx.4

Case 3:  Request forwarded to one destination due to failure of a fork
to another destination.

Destinations are sip:A (rc), falling back to sip:B.

Outgoing request to A:
        History-Info: hhh,
                      <sip:A>;index=xxx.1;rc
Outgoing request to B:
        History-Info: hhh,
                      <sip:A?Reason=SIP%3bcause%3d487>;index=xxx.1;rc,
                      <sip:B>;index=xxx.2
[%3b is ';'.  %3d is '='.]

Case 4:  Request is sent to redirect server which provides 3
destinations, one of which is low priority.

Redirect server is sip:R.

Outgoing request to redirect server:
        History-Info: hhh,
                      <sip:R>;index=xxx.1

Incoming response from redirect server:  [same]

Destinations in 302 are <sip:A;hit=rc>, <sip:B;hit=mp>, and <sip:C>;q=0.1.

Outgoing request to A:
        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:A>;index=xxx.2;rc
[%3b is ';'.  %3d is '='.]
Outgoing request to B:
        History-Info: hhh,
                      <sip:R?Reason=SIP%3bcause%3d302>;index=xxx.1,
                      <sip:B>;index=xxx.3;mp=xxx.1
Outgoing request to C:
        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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Oct 2010 13:57:46 -0400

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