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

From: "Francois Audet" <[email-masked]>
Date: Fri, 21 Oct 2005 14:00:28 -0500

> P.S. In terms of the debate over "telling you what happened so you  
> can figure out what the right thing to do is" versus "telling 
> the SIP  
> infrastructure exactly what to do", I have consistently been in the  
> former camp. In fact, that reasoning was one of the things that  
> motivated both the Reason header and the History-Info work. I have a  
> strong preference to avoid putting service directives into URIs  
> except as a last resort, and only then when you know EXACTLY 
> what you  
> want a server to do and can ensure that the request in fact gets  
> routed to that server.

Some of us view the "telling you what happened so you can figure
out what the right thing to do is" as the Big Magic Box in the Sky...
A little bit like a traditional Central Office.

I think the reality is that there has to be room for both. If you have 
the luxury of having a centralized environment, it probably does make
a lot of sense to use this approach. It's just simpler.

If you don't have this luxury, which happens a lot, the last thing
you want is to have somebody from "Central headquarters", "muck" 
around with what you really want (what you refer to as "knowing EXACTLY 
what you want").

The draft we submitted was definitively in the "knowing EXAXTLY" what
you
want camp.

> > Can't I legimately file a "History-Info" saying I 
> redirected you for a
> > reason? If so, what other reason would you suggest I use?
> >
> > What if the 302 were being generated bya B2BUA instead of a  
> > terminal UA?
> >
> > Or is History-Info just sort of broken when generated by a UA?

I don't think History-Info is "sort of broken" when generated by a UA. 
I do think however that it evolved into something completely different
from 
what it was proposed for in the first place.

Today, it's intent is to reflect what has happened to requests at the
SIP level.
And it does that very well.

(One issue of course is that it is optional, and that most people think
it is a proxy function and not a UA function. If we knew it was always
there,
and always accurate, it would obviously be more usable for important 
services like VM).

History-Info does NOT reflect "redirections withing the PSTN" or other
events that 
occurs outside of its sphere of applicability (SIP). 

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Sun, 23 Oct 2005 19:42:42 -0400

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 24 Oct 2005 08:58:36 -0400

Another thing that occurred to me while reading these drafts is that
there are probably more redirection reasons than are given in the
current table.  For instance, there is a whole class of "redirected
because the UA couldn't handle this call technically", which includes:

401 (Unauthorized, if the UAC has no credentials for that realm)
402 (Payment Required, if the UAC is unable to provide payment info)
405 (Method Not Allowed)
406 (Content Type Not Acceptable)
415 (Unsupported Media Type)
416 (Unsupported URI Scheme)
420 (Extension Not Understood)
421 (Client Extension Required)

And while I was going through 3261 to make that list, I could see that
there were other categories of 4xx responses that could be sensibly
grouped into other categories that are not covered by the current list.

Dale