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

From: [email-masked]
Date: Thu, 3 Jul 2003 17:00:58 EDT

In a message dated 7/3/2003 3:30:15 PM Eastern Standard Time, 
[email-masked] writes:

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

No, I am not suggesting any relationship between namespaces. Each is defined 
and registered separately. On the other hand, if a network chooses to handle 
multiple namespaces (one per call), it must decide how to determine the 
relative priorities when used on different calls that may contend for the same 
resources. There would be no standard and it would not be a part of the registration 
of each namespace.

But if there are multiple namespaces defined that are intended to be used in 
the same "domain" or environment or whatever you want to call it and on the 
same call, then I think it may become necessary to define the relative priority, 
maybe in registration. We need to avoid this.

The inclusion of multiple namespaces (or priorities) in a single SIP call 
setup request leads to the need for defining additional procedures to deal with 
them, including how to decide the sequence in which to try to interpret them.

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

I love analogies. I think including two namespace.priority values in the SIP 
header is more analogous to having two airline tickets, one first class and 
one coach, handing both to the ticket agent, and expecting the agent to pick 
which one to use.

The airline/train analogy would be more like having a header for SIP to use 
and a separate parameter which only ISUP looks at. ISUP knows that it shouldn't 
look at the SIP header, just like the train conductor doesn't look at the 
airline ticket. This makes good sense.

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Jul 2003 17:14:38 -0400

> 
> The inclusion of multiple namespaces (or priorities) in a single SIP 
> call setup request leads to the need for defining additional procedures 
> to deal with them, including how to decide the sequence in which to try 
> to interpret them.

Multiple priorities (A.X and A.Y) for the same namespace seem bad, but 
why would we have to define how a node handles

R-P: A.X, B.Y

? There are any number of reasonable options:

- Look for A; if A exists, ignore anything else.

- Look first for A, then B, then C, then .... Once found, stop and 
ignore the rest.

- Have some total order among the A and B priorities, defined strictly 
by local policy. Find A.X and B.Y and pick the "better" (or "worse") one.

Anything else?

If somebody really sees the need, we can't keep them from publishing 
such a total order ("If A and B are used in the same system, the 
following ordering ...."), but I don't see the need for this right now 
at the IETF standards level.

> I love analogies. I think including two namespace.priority values in the 
> SIP header is more analogous to having two airline tickets, one first 
> class and one coach, handing both to the ticket agent, and expecting the 
> agent to pick which one to use.

Not quite: Y and C tickets are from the same namespace. Think of having 
a Delta Gold/Silver Medaillon and a Business/Economy Ticket.

> 
> The airline/train analogy would be more like having a header for SIP to 
> use and a separate parameter which only ISUP looks at. ISUP knows that 
> it shouldn't look at the SIP header, just like the train conductor 
> doesn't look at the airline ticket. This makes good sense.

Again, a SIP request may visit any number of different administrations 
along the way to its destination, often unpredictable by the sender (due 
to name translations, among many other reasons).

> 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