Subject: Re: [IPTEL] CPL Question About Priority

From: [email-masked]
Date: Tue, 28 Nov 2000 16:03:27 -0500

From:  Tom Gray@MITEL on 11/28/2000 04:03 PM

This would be useful for 'one number' services in whjch a priority list of
numbers are given where  person possibly may be found.  Wheter CPL is an
appropriate mechanism to program such a feature is problematic.

Jonathan Lennox <[email-masked]> on 11/28/2000 03:56:35 PM

To:   [email-masked]
cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)

Subject:  Re: [IPTEL] CPL Question About Priority

On Monday, November 27 2000, "[email-masked]" wrote to
"[email-masked]" saying:

> The "location" node has an optional "priority" parameter, but the "lookup"
> node does not. Nor does the CPL draft specify the priority of the location
> initially in the location set for an outgoing call.

The assumption is that lookups will supply priorities.  The model is of SIP
registrations, which have associated 'q' values.

It's true that there's no priority specified for the initial address.  I
suppose it should be 1.0.

> Suppose I wanted to write a script that, for outgoing calls, tried some
> other number first, and if that call failed, then tried the original number.
> It seems to me that there is no portable way of doing that, since the
> priority of the location initially in the location set is not specified.

No, there isn't any way to do this in the CPL.  In what circumstance would
you want to do it?  Remember that CPL is deliberately not a Turing-complete
language, and deliberately we restricted it to only the sorts of component
primitives that we thought would be useful.

> Section 7.1 says, "The priority of locations in a set is determined by
> server policy, though CPL servers SHOULD honor the priority parameter of the
> location tag." Why is this only a SHOULD and not a MUST? And why are no
> priorities defined for the other cases mentioned above?

I didn't see any reason to force a MUST, in case there were other server
policies that were invoked.

--
Jonathan Lennox
[email-masked]

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 28 Nov 2000 16:08:55 -0500 (EST)

> appropriate mechanism to program such a feature is problematic.

'One number' services are a standard CPL feature -- on the *destination*
side, where the list of locations is provided through <location> or <lookup>
nodes.  I could even potentially see such services on an origination side,
as in "if I call Joe@home, assume I really mean both Joe@home and
Joe@hiscellphone".  But I understood the the feature Cliff was describing as
"If I call anyone at Example Industries, first place my call to the Example
Industries switchboard, then try that specific person."  It's not clear to
me why anyone would ever want such a feature for their outgoing call script.

-- 
Jonathan Lennox
[email-masked]

---

From: hammer michael <[email-masked]>
Date: Wed, 29 Nov 2000 09:56:10 -0800

You could potentially have a network selection based on dynamic network 
characteristics.
Route through network A (the cheapest) unless it is congested or denies me 
service,
otherwise route through network B while QoS > X, else ...

I know that bandwidth is supposed to be free and plentiful, but could you 
foresee networks of the future dynamically changing their rates based on 
demand and users selecting the better alternatives for routing?

Mike

At 04:08 PM 11/28/2000 -0500, Jonathan Lennox wrote:
>On Tuesday, November 28 2000, "[email-masked]" wrote to "Jonathan 
>Lennox, [email-masked], [email-masked]" saying:
>
> >
> >

---

From: hammer michael <[email-masked]>
Date: Wed, 29 Nov 2000 10:07:48 -0800

An additional thought:

What if I as a service provider wanted to differentiate service between 
paying and non-paying customers?
Based on the origination number, I give better or worse service.

Mike

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 29 Nov 2000 12:22:23 -0500 (EST)

> demand and users selecting the better alternatives for routing?

Yes, absolutely, but this is way out of scope for the CPL.  Remember, CPL
controls *signalling*, and the network selection you're talking about is for
*media*.

If I place a call to sip:[email-masked], and the 200 response to the INVITE
has 128.59.19.147 in its SDP, I'm going to send my packets to 128.59.19.147,
regardless of what route my INVITE took.

If I'm using manyfolks, I'll also set up a resource reservation to that IP
address.  That's the point at which the service provider should intervene to
figure out what route they want my packets to take.

-- 
Jonathan Lennox
[email-masked]

---

From: hammer michael <[email-masked]>
Date: Wed, 29 Nov 2000 14:16:00 -0800

I understand to an extent the distinction you are making, that the IP 
layer, given the end-point address can figure out how to route the packets 
carrying the media along with resource reservations.  However, the 
existence of Via, Route, and Record-Route parameters and the usage for 
routes longer than two proxies would seem to undermine the purity of your 
position.  Ultimately the purpose of signaling is to establish the media 
path, so they are not so totally divorced.

I thought that one of the evolutionary goals of the IP telephony was to put 
as much control in the hands of the end-user.  If such control is in the IP 
layer, how does the user control that?  Will that be a Web-level interface 
or must he be an IP guru?  I was envisioning a little more control in the 
Application layer via some more user-friendly features.  In the current 
PSTN, there is some level of stimulus signaling for customers to activate 
and deactivate features and program-in network codes and user phone numbers 
for forwarding.  I would expect that the level of user control would be 
much higher in IP telephony.

Do you see the network cloud operating transparently and what service you 
get is what you get?
Or is there another media-specific protocol that allows the user to 
explicitly control what network routes that his packets traverse?

Mike

At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
>On Wednesday, November 29 2000, "hammer michael" wrote to "Jonathan 
>Lennox, [email-masked], [email-masked], 
>[email-masked]" saying:
>

---

From: Lakshmi Krishnamurthy <[email-masked]>
Date: Wed, 29 Nov 2000 15:06:14 -0600

I agree with this observation. The application always knows best in 
terms of the nature & type of resources it needs accomodated by the 
network. There needs to be a way of communicating this requirement to 
the IP layer.

This need not be an explicit list of QoS params, but something that is a 
user-friendly mapping could be in order.

hammer michael wrote:

> layer, given the end-point address can figure out how to route the 
> packets carrying the media along with resource reservations.  However, 
> the existence of Via, Route, and Record-Route parameters and the usage 
> for routes longer than two proxies would seem to undermine the purity 
> of your position.  Ultimately the purpose of signaling is to establish 
> the media path, so they are not so totally divorced.
> 
> I thought that one of the evolutionary goals of the IP telephony was 
> to put as much control in the hands of the end-user.  If such control 
> is in the IP layer, how does the user control that?  Will that be a 
> Web-level interface or must he be an IP guru?  I was envisioning a 
> little more control in the Application layer via some more 
> user-friendly features.  In the current PSTN, there is some level of 
> stimulus signaling for customers to activate and deactivate features 
> and program-in network codes and user phone numbers for forwarding.  I 
> would expect that the level of user control would be much higher in IP 
> telephony.
> 
> Do you see the network cloud operating transparently and what service 
> you get is what you get?