Subject: [Sipping] Service definitions and draft-elwell-sipping-service-retargeting

From: Dean Willis <[email-masked]>
Date: Fri, 14 Oct 2005 16:47:32 -0500

This draft proposes request-URI parameters used to encode what is  
essentially history information into a request URI when that request  
is being made to invoke a "service". This has left me pondering a few  
things.

Exactly what constitutes a "service"? Do we need to have an  
enumerated set of services like 3GPP has proposed? My initial thought  
is that this is a Really Bad Idea that would rapidly be enshrined in  
my list of Evil SIP Things.

Is contact-routing (that is, forwarding a request sent to an AOR to  
contacts registered against that AOR) a reportable service? For  
example, the user profile could say "Forward all to voicemail". The  
retargeting draft would appear to consider this a "service". So if  
the user profile says "Fork all calls to the registered contact set,  
and if none send a 200 OK, then forward the call to voice mail", do  
the contacts need to know that they're getting this INVITE due to  
contact-routing? Does the voice-mail system need to know that the  
call was previously sent to the contact set and that the only one  
that responded sent a 486? And what part of this is a "service"?

On a related note:

The retargeting draft says:

    - The SIP response codes captured by [HIST] are dependent upon
    whether retargeting is as a result of recursion or not. When
    recursion is used, the SIP response code will always be in the 3xx
    range, but otherwise, even if the reason for retargeting is
    identical, the reason will not be in the 3xx range. For example, if
    retargeting is due to the previous target being busy, the SIP
    response code used without recursion would normally be 486, but with
    recursion it would have to be a 3xx response code (e.g., 302).

This confuses me. Let's spell it out:

Alice--->Proxy---->B
            |
            ------->C

First use case:

B is a registered contact for Bob. Alice sends a request for Bob to  
Proxy. Proxy sends the request to Bob's contact B, which returns a  
302. Proxy then recurses on the 302 and sends the request to C.

Here, we've had two proxy operations of historical importance by the  
time the INVITE arrives at C

1) Proxy selected contact B and sent the request to B, which returned  
a 302. Note that B might never indicated WHY it returned a 302, which  
is the subject of another draft on redirection reasons. Or, B might  
have returned an appropriate History header, as indicated by  
requirement  4) ISSUER-req in "draft-ietf-sip-history-info-06".

2) Proxy acted on the 302 and sent the request to C.

C might see a request with History-Info header fields as follows.  
Note that I've NOT escaped the H-I reason codes to aid in  
readability. Also note that there are some things in History-Info I  
don't understand, especially around the underdocumented response  
usages, so this could be wrong:

History-Info:<sip:bob@proxy>;index=1
History-Info:<sip:bob@b>;index=2
History-Info:<sip:bob@c?Reason=SIP486>;index=3
History-Info:<sip:bob@c?Reason=SIP302>;index=2.1

Now according to history-info-06 4.3.1 para 2, C knows that this  
request came to it because a previous node was 486.

Second use case:

B and C are registered contacts for Bob. Alice sends a request for  
Bob to Proxy, which implements sequential contact routing. Proxy  
sends the request to Bob's first contact B, which returns a 486.  
Proxy then routes the request to the next contact, C.

Again, we've had two proxy actions by the time the call reaches C:

1) Proxy selected contact B and sent the request to B, which returned  
a 486.

2) Proxy acts on 486 by going on to next contact, C.

The History-Info header fields here might look like:

History-Info:<sip:bob@proxy>;index=1
History-Info:<sip:bob@b>;index=2
History-Info:<sip:bob@c?Reason=SIP486>;index=3
History-Info:<sip:bob@c>;index=2.1

Note that C still knows the previously-tried node was busy. It just  
doesn't know that the proxy routing decision resulted from contact- 
routing, whereas in the previous use case it knew the proxy logic was  
driven on a 302.

Questions:

Was C reached because of "normal" contact routing, or was C reached  
because of  special "busy" service routing?

Is this a different "service" from the previous case?

If so, should the request-URI presented to C be the same?

Third use case:

B is the only registered contact for Bob. Alice sends a request for  
Bob to Proxy. Proxy sends the request to Bob's contact B, which  
returns a 486. Bob's service profile says that if his contacts are  
all busy, to route requests to C. So Proxy sends the request to C.

Again, we've had two proxy actions by the time the request reaches C:

1) Proxy selected contact B and sent the request to B, which returned  
a 486.

2) Proxy selects a new target C (not from the contact set) and send  
the request there?

and the History-Info header fields here might look like:

History-Info:<sip:bob@proxy>;index=1
History-Info:<sip:bob@b>;index=2
History-Info:<sip:bob@c?Reason=SIP486>;index=3
History-Info:<sip:bob@c?Reason=SIP486>;index=2.1

Questions:

How does this differ from the previous case?

what makes this a "service" where the second use case wasn't one?

I'm worried that somewhere down deep inside, we're reasoning from the  
principle that "If it looks like something that the PSTN would have  
called a service, it must be a service, and if it doesn't, it must  
not be". I'm also worried that the History-Info document is a bit  
light on guidance about the allowed use-in-request and on use-cases  
in general.

--
Dean

_______________________________________________
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