Subject: RE: [Sipping] Service definitions and draft-elwell-sipping-servic e-retargeting

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Oct 2005 10:27:41 +0100

Dean,

Thanks for your comments. See in-line.

John

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 14 October 2005 22:48
> To: Sipping List
> Subject: [Sipping] Service definitions and 
> draft-elwell-sipping-service-retargeting
> 
> 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.
[JRE] Service-retargeting is proposed as an alternative to
redirection-reason, to get around the problem that redirection-reason needs
special support at the UAC, firstly to support History-Info and then to copy
a redirection reason from the 3xx response into the History-Info header.

> Or, B might  
> have returned an appropriate History header, as indicated by  
> requirement  4) ISSUER-req in "draft-ietf-sip-history-info-06".
[JRE] I don't think this requirement extends to redirect servers that issue
302 responses. In any case, I don't think there is mechanism within
history-info to satisfy this requirement, if it is intendede to apply to 3xx
responses.

> 
> 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
[JRE] I don't think this entry will be included.

> 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?
[JRE] It should not in principle be different, but is is because different
because of the inability for the UAS to convey "busy" in the 302 reponse.

> 
> 
> 
> 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
[JRE] There would not be a Reason header in the last URI.

> 
> Questions:
> 
> How does this differ from the previous case?
> 
> what makes this a "service" where the second use case wasn't one?
[JRE] It need not be considered different. Both could be treated as a
"service". Or neither could be treated as a "service" - it depends how the
proxy is programmed to behave.

> 
> 
> 
> 
> 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
> 

_______________________________________________
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