RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

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

I've been only skimming this conversation, but I see some sort of
impedance mismatch between the facilities people are discussing and the
realities.  Or at least, the realities of how our SIP system (the sipX
open-source SIP PBX) is architected.

(This is based on the two drafts I've seen, draft-elwell-sipping-
service-retargeting-00.txt and draft-elwell-sipping-redirection-
reason-02.txt, though I must admit I've not studied either of them
well.)

In the sipX system, a request is first passed to the "forking
proxy" (FP), whose job is to handle the mechanics of forking.  The SIP
domain name routes to FP.

If the request URI is within the PBX's domain, it is forwarded to the
"redirect server" (RS), whose job is to determine the proper contacts
for the URI.  RS has a set of modules which generate contacts.  Most
commonly, one module generates the list of user agents that have
registered for the AOR, and another module generates a URI pointing to
the voice mail server.  This voicemail contact has an attached "q=0.1"
parameter so that it has lower priority than the user agent contacts
(which default to "q=1.0").

RS then sends a 302 response to the request, listing all of the contacts
it has found.

FP recurses on the 302, doing the appropriate sequence of
serial/parallel forking -- the request is forwarded to contacts in
decreasing q order, with contacts that have the same q value handled in
parallel.  The request goes to a particular contact only if the request
has failed to all contacts with higher q values.

In this context, there seems to be two types of "retargeting reasons".
The first one is "Why is this URI a contact for this AOR?"  It can only
be discerned by RS.

Presumably we want a way that RS can insert this information into its
302 response so that FP can incorporate it into the fork to the contact
in question.

The second retargeting reason is "Why did the call not get serviced by
some previous fork of this request?"  This can only be discerned by FP.
As far as I can tell, all possible information for this question is
encompassed in the failure response to the previous request (and any
accompanying Reason header).  (Really, it is in this information for the
failure responses to *all* the higher-q contacts.)

Looking at the list of reasons in section 4 of redirection-reason and
section 6 of service-retargeting, I see that these two sorts of
information are conflated in the PSTN world.  Most of the reason codes
(diversion on busy or no answer) are of the second type, whereas hunting
a/k/a distribution is of the first type.  (I suspect that a whole host
of the "uninteresting" retargeting reasons (like registered user agents)
also fall in the first type.)

And the situation is messier than even my exposition -- compare the sipX
situation where a call automatically cascades to a lower-priority
contact if a higher-priority one is busy vs. a user agent that responds
to a request with a 302 containing the "forward to if busy" contact.  In
the first case, the ultimate contact is a contact for the AOR for some
unrelated reason, but the request goes to it because the first contact
was busy.  In the second case, the ultimate contact was a contact for
the AOR only because the first user agent was busy; if the first user
agent did not answer, another URI might have been the next contact.

One case to exercise proposals with is one that sipX provides routinely:
A "hunt group" of four user agents.  Any call to the hunt group URI
receives all four user agent URIs in some particular q-value order, but
each call gets a new set of random q-values.  If a request comes to the
hunt group URI, and it is sent to the first user agent, and it does not
answer, so the request is sent to the second user agent, and it does not
answer, so the request is sent to the third user agent -- exactly what
should be the "retargeting" information on the request when it reaches
the third user agent?  That contact was derived from the original URI
via the hunt group mechanism, but it was only contacted because the
first two user agents did not answer.

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