Subject: [Sip] Re: multiple namespaces for SIP RPH

From: [email-masked]
Date: Thu, 3 Jul 2003 15:12:22 EDT

In a message dated 7/3/2003 10:27:35 AM Eastern Standard Time, 
[email-masked] writes:

> In the US PSTN, a call may be a GETS call AND a WPS call; a GETS call BUT 
> NOT a WPS call; or a WPS call BUT NOT a GETS call.
> The "labels" for a GETS call and a WPS call are different (CPC parameter vs. 
> Precedence parameter) 
> Being a GETS call determines treatment in the landline network.  Being a WPS 
> call determines treatment in the wireless network.
> It seems plausible that a similar situation could occur in  IP networks - 
> especially if one treatment was relevant in one administrative domain, but 
> another was available in a second administrative domain.
> 

Yes, clearly a call can have multiple markings. It seems that we already have 
lots of possibilities, both in the circuit-switched world and IP. CPC, and 
its origins in SS#7 and US signaling, is one of them.

I just think that the Resource-Priority header and its purpose require that 
only one value (namespace) be carried in any single call setup attempt. That 
single value may then cause different actions or results for a wireless access, 
a wired access, an IP access link, a core link, a gateway, etc. The point is 
that the definition of the value needs to take into account all the 
requirements. If the Wireless access portion needs the 5 levels defined for WPS but GETS 
only needs one level while a regular call needs a "normal" level then we could 
define 6 levels. Once the call setup gets beyond the wireless access portion, 
the 5 individual levels defined for WPS may be treated the same. For 
assigning priority in a network, the level for GETS needs to be assigned relative to 
the WPS levels.

The R-P header should not be seen as a way to label the type of call (GETS, 
WPS, etc). It should just be a relative priority. If there is a need to label a 
call as WPS, or GETS, or something else, then there needs to be an explicit 
label for that (which allows either or both). The "namespace" should not be 
used for this.

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Jul 2003 15:29:40 -0400

Are you suggesting something that is essentially the cross-product of 
all priority namespaces? That seems rather unworkable.

There is no need to resolve the relative priority of A.X vs B.Y if they 
are not used by the same system (different administrations), i.e., they 
are orthogonal. If they are used by the same system, that system can 
presumably work out what it means if it receives a request containing 
both A.X and B.Y. This does not require standardization; in particular, 
there are any number of reasonable solutions, including a "virtual 
resource", so that the system sets aside some fraction for A.* and some 
fraction for B.*. It might do some internal ordering, but as long as the 
partial order with A.* and B.* is maintained, this doesn't seem to cause 
any difficulties.

I think of this as analogous to having both a 2nd class train ticket and 
a business class airfare - you need to carry both tickets with you as 
you travel, but the train conductor doesn't care about your airline 
ticket and vice versa.

[email-masked] wrote:

>> In the US PSTN, a call may be a GETS call AND a WPS call; a GETS call 
>> BUT NOT a WPS call; or a WPS call BUT NOT a GETS call.
>> The "labels" for a GETS call and a WPS call are different (CPC 
>> parameter vs. Precedence parameter)
>> Being a GETS call determines treatment in the landline network.  Being 
>> a WPS call determines treatment in the wireless network.
>> It seems plausible that a similar situation could occur in  IP 
>> networks - especially if one treatment was relevant in one 
>> administrative domain, but another was available in a second 
>> administrative domain.
> 
> 
> 
> Yes, clearly a call can have multiple markings. It seems that we already 
> have lots of possibilities, both in the circuit-switched world and IP. 
> CPC, and its origins in SS#7 and US signaling, is one of them.
> 
> I just think that the Resource-Priority header and its purpose require 
> that only one value (namespace) be carried in any single call setup 
> attempt. That single value may then cause different actions or results 
> for a wireless access, a wired access, an IP access link, a core link, a 
> gateway, etc. The point is that the definition of the value needs to 
> take into account all the requirements. If the Wireless access portion 
> needs the 5 levels defined for WPS but GETS only needs one level while a 
> regular call needs a "normal" level then we could define 6 levels. Once 
> the call setup gets beyond the wireless access portion, the 5 individual 
> levels defined for WPS may be treated the same. For assigning priority 
> in a network, the level for GETS needs to be assigned relative to the 
> WPS levels.
> 
> The R-P header should not be seen as a way to label the type of call 
> (GETS, WPS, etc). It should just be a relative priority. If there is a 
> need to label a call as WPS, or GETS, or something else, then there 
> needs to be an explicit label for that (which allows either or both). 
> The "namespace" should not be used for this.
> 
> Mike Pierce

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