Subject: [Sipping] Telling a proxy which service to execute

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 02 Nov 2005 19:42:15 +0200

Folks,

it seems to me that the History-Info approach can meet the requirements 
coming from services that need to know what has happened to this request 
so far.

Now, we will need a solution for the model in which proxies instruct 
other proxies (or application servers) down the path which service to 
execute. (Assuming somebody has requirements to support this model as well.)

It has been proposed (in 
draft-elwell-sipping-service-retargeting-00.txt) to use URI parameters 
for that. This approach has been compared by some in the list to the 
approach followed by netann (draft-burger-sipping-netann-11.txt).

It is worthwhile noting that using URI parameters to convey service 
information (on any type of information) has an important problem. If 
the request traverses a proxy that does not understand the URI 
parameter, the URI parameter may be removed. That is the reason why we 
moved away from URI parameters to implement URI-list services (a.k.a. 
exploders).

While netann deals with media servers whose URI typically routes 
directly to them, service retargetting deals with users. Requests 
addressed to the AoR of a user may traverse a set of nodes before 
reaching the proxy or application server that needs to execute the 
service, or the user agent itself.

This means that URI parameters would only work in scenarios where it is 
ensured somehow that every node handling the request understands these 
URI parameters.

So, if we want a more general solution, we will need to look into header 
fields.

Cheers,

Gonzalo

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Wed, 2 Nov 2005 15:30:32 -0600

On Nov 2, 2005, at 11:42 AM, Gonzalo Camarillo wrote:

> So, if we want a more general solution, we will need to look into  
> header fields.

I'm beginning to have the thought that this may be something like the  
end-to-middle (or even middle-to-middle) problem.

That is, we're inserting some parameters (that might need to be  
inserted securely) at one node on the proxy chain so that they can be  
used by another, probably non-adjacent node on the proxy chain.

There would seem to be variant cases, depending on security,  
targeting of the consumer node by identity versus role, and  
parameters that are meant to be delivered to the terminal UAS (or, is  
that just a role?). Very interesting.

I'm taking the rest of the afternoon off, my head is now full.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 3 Nov 2005 08:16:28 +0100

> While netann deals with media servers whose URI typically routes directly 
> to them, service retargetting deals with users. Requests addressed to the 
> AoR of a user may traverse a set of nodes before reaching the proxy or 
> application server that needs to execute the service, or the user agent 
> itself.
>
> ensured somehow that every node handling the request understands these URI 
> parameters.
>

Another way to look at this, is to consider the service provided by a proxy 
as an addressable (logic) entity. The desired final destination could then 
be provided as a parameter to the service, as follows:

REQUEST sip:[email-masked];AoR=[email-masked] 
SIP/2.0

Regards,

Jeroen