[Sipping] Thoughts about draft-mahy-sipping-herfp-fix-00.txt

["Dale Worley" <[e-mail]>]

1. First off, this proposal sounds like a really good idea.  But I
think that the idea is better than the author realizes, and by
exploiting some of the powers of SIP, we don't need to add as much
machinery to SIP as is described in the I-D.

Also, we need to work on a cool acronym for this idea.  Personally, I
like HERP, as in the first syllable of "herpetology".  So I will call
a UAS that understands the HERP mechanism "a HERP UAS", a proxy that
understands the HERP mechanism "a HERP proxy", etc.

I've written these notes based on how I see HERP working, without
pointing out specifically how it differs from the I-D, or which ideas
others have explored.  Sorry about that, I'm a bit rushed these days.
The central idea is:

    The 130's are additional and separate from the RFC 3261 forking
    logic, and provide a way of promptly delivering to the UAC failure
    responses that might not be returned to the UAC promptly by the
    forking logic.  The UAC uses the 130's to determine if it wishes
    to send further INVITEs as forks of its transaction.

This ensures that HERP does not induce anomalous behavior in the
existing forking logic.

2. A HERP UAS can generate a 130 on its own account, instead of
leaving the work to an upstream proxy.  Similarly, a proxy that
generates a repairable 4xx response can generate a 130 for that
response.  Though perhaps we don't want them to do this, since they
don't have knowledge that the delivery of their failure responses to
the UAC will be delayed.  Perhaps we want to encourage that only
proxies will generate 130's for failure responses they receive that
they will not be promptly forwarding upstream.

3. In general, an INVITE can go through more than one HERP proxy, so
we need a way to tag a failure response from one HERP proxy so that
upstream HERP proxies will know a 130 has already been generated for
this response.  Of course, this requires HERP proxies to keep track of
which of the failure responses that they have received were tagged, so
when they select one to forward, they can tag it or not as
appropriate.

I propose that we create a new header for indicating this information,
perhaps "HERP:  generated".

4. One possibility to simplify things would be too make 130's
unreliable (unless, orthogonally, the transaction is using PRACK).

5. If we want keep 130's reliable, we need more machinery.  It seems
that we can decouple the re-sending of 130's from the forking
transaction context that generated them, and consequently simplify the
HERP proxy logic:  When a HERP UAC receives a 130 and re-sends an
INVITE, the INVITE should be considered a fork of the transaction at
the UAC, not part of the transaction at the proxy that sent the 130.

(Necessarily, the from-tag and Call-Id in the re-INVITE are the same
as those in the original INVITE, as they are part of the same
transaction.)

In particular, the further processing of the forking transaction in
the proxy is not affected by any 130's that it has generated -- it
terminates and forwards a response as it would without 130's, and
regardless of whether the 130's have been confirmed or not.  The 130's
form a parallel but independent notification system that allows the
UAC to retry INVITEs faster, but "on its own account".

If a re-INVITE succeeds, its 200 travels back to the UAC, which then
cancels the original INVITE in the ordinary way, as the re-INVITE and
the original INVITE are forks of the same transaction.

6. Assuming that the proxy generating the 130 isn't the SIP agent
generating the original failure response, the proxy needs to pick its
own to-tag to conform to RFC 3261; otherwise there would be two
responses in the same dialog with different Contact/Record-Route
information and that might confuse some SIP agents.  (The to-tag of
the failure response is still available in the sipfrag in the body of
the 130.)

7. Confirming the authenticity of a 130 response will be nearly
impossible in any situation where more than one proxy does non-trivial
forwarding, without establishing a full framework for authentication.
But this problem is no worse than that now extant for 302 responses.
Thus, I think that we should not mandate a higher level of
authentication for 130's than we now require for 302's.

8. Some thoughts about getting the routing of the various messages to
work in situations without global connectivity:  I may have some of
the details wrong, as I've not worked with SIP routing that much, but
I think that these are the critical problems.

A. The context that is created to allow re-transmission of a 130
response remembers the INVITE as it arrived at the HERP agent and the
failure response as it arrived at (or was generated by) the HERP
agent.

B. The 130 is sent as a response to the INVITE as it arrived at the
HERP agent, with the Record-Route's copied, any unconsumed Route's
deleted, and the Contact is a URI that will reach the HERP agent
following the route set, and carries a URI parameter(?) that specifies
the 130's context.  (This implies we should standardize a URI
parameter name for HERP agents to use, knowing that it will not
interfere with any other use of URI parameters.)  The Contact reaches
the HERP agent (rather than the agent that generated the original
failure response) so that the HERP agent can determine when the UAC
received the 130 and thus cease retransmitting the 130.

(When the UAC receives the 130, an early dialog is created by it.  But
the UAC can omit making any record of the early dialog, as no further
use of that dialog will ever be made.)

C. If the UAC wants to confirm that it has received a 130 but does not
want to issue a re-INVITE, it should send a BYE to the 130's Contact
instead.  (Being the caller, it is allowed to send a BYE to an early
dialog -- section 15, para. 1.)  (A CANCEL can't be used, as there is
no chain of transactions from the UAC to the HERP proxy that only
forks to the HERP proxy -- CANCEL is hop-by-hop, and forks exactly
like the INVITE it is canceling.  CANCELing the original INVITE would
be non-productive, and there is no re-INVITE that goes directly to the
HERP agent.)

D. If the UAC wants to re-try the request, it issues an INVITE with
the route-set it received from the 130, and the request-URI from the
Contact in the 130.

The INVITE will be routed in the usual way to the HERP agent that
generated the 130.

The HERP agent then appends some additional Route headers, and changes
the request-URI to the Contact from the original failure response.
(The additional Route headers are derived from the Record-Route's in
the original failure response that were in addition to the
Record-Route's that were present in the original INVITE as the HERP
agent received it.  They are the route to get from the HERP agent to
the agent that generated the failure response.)

(This presents a problem:  Unless the agent that generates the failure
response includes the "extension number" in its Contact, there is no
way for the UAC or proxy to generate a new INVITE that fully
duplicates the request-URI that was received by the failing agent, as
there is nothing that compels the failing agent to report the
request-URI in the INVITE it rejects.)

The INVITE will then be routed in the usual way to the agent that
generated the original failure response

E. A 130 context retransmits until a PRACK, BYE or INVITE is received
for the unique URI that was used as the Contact of the 130.  (For
upward-compatibility, we should probably specify that retransmission
is quenched by receiving any request to the unique URI.)

F. A 130 context is destroyed by timeout, receiving a PRACK for the
130, or receiving a BYE, CANCEL or ACK for a re-INVITE sent to the
130's unique URI.  (The ACK is seen only if the HERP agent
Record-Route's itself on the re-INVITE.  We may want to not destroy
the 130 context for a BYE or CANCEL, so if the BYE/CANCEL is
retransmitted, we can re-send 200 OK rather than "transaction
unknown".  Better, we may want to leave the retransmission of the
response to a BYE/CANCEL to a lower layer, but destroy the
higher-level 130 context.)  Or we may want to just have all 130
contexts destroyed only by timeout.

(The timeout is timer C, the "proxy INVITE transaction timeout" --
once the original INVITE has timed out, all 130's for it are useless.)

9. We need to specify a token for the Supported header to request HERP
processing.

For broadcast or multicast type operations, a UAC may wish to not
request HERP processing even if it can support it, in order to avoid
being flooded with 130's.

10. A HERP proxy should assume that any failure response (other than
6xx responses) is potentially repairable, unless it has knowledge of
the semantics of that particular response code that it can never be
repaired.  On the other hand, a UAC should assume that a failure
response is repairable only if it has knowledge of that particular
response code.

11. Initially, I worried that the re-INVITEs generated by HERP might
be quashed by loop detection, but Dan Petrie tells me that current
best practice is that the determination of duplicate INVITEs should
only be done only by the target UA that would act on them, as it is
the only agent that can reliably determine when two INVITEs are
semantically identical.  In this case, we expect that the UAC will be
forming a re-INVITE that is different from the original INVITE as the
target UA sees it, and so will not be rejected with 482.

Dale


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP