Subject: [Ieprep] requirements document(s) to SIPPING

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 17 Sep 2002 08:18:42 -0400

Recall that we need to get requirements document(s) to SIPPING.  I would
like us to focus on the VoIP scenario with SIP for a moment with the
scenarios of IP to Circuit-Switched Network (CSN), CSN to IP to CSN (SIP
bridging), or CSN to IP.  Where it makes sense, we can also consider other
real-time SIP sessions such as instant message or conferencing.

One could examine this in stages:

1. Preserve any priority scheme in the CSN when applying SIP bridging

This would prevent loss of information in the CSN.  It might also make sense
to limit this case to where both CSN's use the same priority scheme (e.g.,
suppose CSN 1 is employing MLPP.  Then MLPP information is presented in full
to CSN 2 but there is no attempt in the IP network to translate MLPP into a
different priority scheme).

Question for WG:  Can this be done with existing RFCs or new drafts?  Are
there any specific security or other requirements in this case?

2. Introduce priority scheme at SIP endpoints (e.g., SIP user agents,
gateways, media servers).

This would allow new optional functionality such as providing emergency
users preferred access to gateway or media server resources, allowing
preemption to occur at endpoints, etc.  This option increases complexity and
has security issues that will also need to be addressed.

Questions for WG:  What are the requirements for these endpoints?  Would a
SIP endpoint be required to determine what priority scheme(s) a gateway
employs?  Would the gateway be required to communicate the security
information it must have before allowing priority access to resources?  

3. Introduce priority of SIP messages within SIP proxy servers.

This would allow certain SIP messages to have preferred treatment over other
messages.  Now on the surface, it might seem like this kind of preferred
treatment addresses one of the working groups expressed concerns -
congestion.  However, there are different types of congestion.  

In reviewing some prior messages to this list, it seems a great deal of
emphasis has been placed upon QoS so that packets associated with emergency
communications are less likely to be dropped during transport in the event
of congestion.  This type of prioritization is in the realm of techniques
like DiffServ or RSVP and hence out of scope for SIP or SIPPING.  

The priority of SIP messages within SIP proxy servers isn't likely to
address the transport congestion issue-SIP proxies typically don't have
knowledge of QoS resources and SIP messages don't typically traverse the
same path as the media streams.  The congestion with respect to gateway or
other endpoint resources has been handled in 2 above.  

So, what SIP proxy server prioritization could do is possibly help a server
decide which message requests in setting up sessions should be preferred.
It was pointed out in the joint IEPREP-SIPPING meeting in Yokohama, that SIP
proxies are fast and prioritizing the individual handling of messages may
have limited value.  SIP proxies must also be DOS resistant.  Also recall
that there are many SIP requests per session and they occur in both
directions.  Suppose a caller with priority calls a caller with regular
capabilities.  SIP proxies will send setup requests in both directions.
Would one want priority treatment of exclusively the direction from the
priority user to the regular one?  If not, there will be additional
complexity and security concerns in "transferring" the priority of the
caller to that of the callee.  There is also complexity in checking requests
have the necessary authentication per SIP message, per SIP proxy over
possibly different security domains.  This is a formidable problem for a
feature whose utility has already been questioned (see
http://www.softarmor.com/sipping/meets/ietf54/slides/ieprep-sipping-joint.pp
t ).

Given the above and our tight deadlines, I am going to suggest we first
focus on the requirements for 1 and 2 above.

Kimberly

_________

Dr. Kimberly S. King
Principal Network Engineer

Science Applications International Corporation
1710 SAIC Drive
MS 1-3-9
McLean, Virginia 22102 USA
phone: (703) 676-7949
fax: (703) 356-2160
[email-masked]
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: [email-masked]
Date: Tue, 17 Sep 2002 15:38:06 EDT

> Question for WG:  Can this be done with existing RFCs or new drafts?  Are

[MAP] For support of "MLPP" in the "SIP Bridging" case, it makes sense to 
assume that both CSNs use the same priority scheme, since there is an 
international standard for this. However, one can not assume that both CSNs 
use the exact same ISUP. While existing RFCs/drafts would support the "MLPP" 
parameters, they do not support the interworking of slightly different ISUP 
versions. But that is not for IEPREP to solve.

For other priority schemes (e.g., emergency service) there may not be an 
exact match between two networks nor does there need to be. One or the other 
gateway must provide interworking (mapping) between two different sets of 
priority values, just as the interworking point between two different ISUP 
versions today might have to map some parameter which is not fully 
compatible. That mapping in the SIP gateway is part of the ISUPside of the 
implementation and thus not of direct concern here (in the "SIP Bridging" 
case).

The security requirement for the bridging case is really no different for 
"MLPP" or other priority services. It must be solved for regular call setup, 
that is, the egress gateway must verify that the call it is asked to send 
back into the CSN came from a legitimate originator (whether ingress gateway 
or another SIP user).

As I see it, pure "SIP bridging" is intended to pass things like priority 
level transparently through SIP and prevents the use of this information in 
providing preferential treatment within the IP world. I don't believe this is 
sufficient to address the problem.

> information it must have before allowing priority access to resources?  

[MAP] It certainly would not be good if an endpoint (originating a call) 
needed to know anything about a gateway that might be used to get the call 
into the PSTN.

> congestion.  However, there are different types of congestion.  

[MAP] This seems to be referring to treatment of the SIP messages used for 
call control. See notes below.

> like DiffServ or RSVP and hence out of scope for SIP or SIPPING.  

[MAP] This seems to be referring to packets transferring the user's 
information, i.e., voice. The issue with QoS (and dropping) should not be 
viewed as giving the emergency call "better" QoS. They need the normal QoS, 
and can even tolerate worse if needed to get the call through. My suggestions 
of a preferential treatment in the case of congestion was to first drop media 
packets for the lower priority call so that it gets worse QoS. If it gets too 
bad, the parties will hang up, thereby freeing up the resources for the 
higher priority calls. (This also presumes sufficient CAC to prevent the 
lower priority call from being immediately reconnected.)

> other endpoint resources has been handled in 2 above.  

[MAP] To get to an endpoint, the SIP messages would have to traverse the same 
path as the media stream if there is only one path available. (Maybe we have 
a different understanding of what a "path" is in this case.) The issue of 
priority of SIP messages is not so much of one message having priority over 
another, but how do you manage the relative priority of SIP (call control) 
messages vs media packets that need to share the same bandwidth.

> So, what SIP proxy server prioritization could do is possibly help a server

[MAP] There should not be any prioritization of SIP messages, in the sense of 
either sending or processing one before the other, since this just makes the 
out-of-order problem more serious. As I suggested in 
draft-pierce-pref-treat-examples.00, there may be utility in applying 
different drop precedences to various SIP (call control) messages, just as 
was done in ISUP, in order to deal with congestion in whatever path is used 
to transfer these messages. However, if these messages are sharing a 
transport path with media streams, it is probably always better to send the 
messages and drop some media packets.

> http://www.softarmor.com/sipping/meets/ietf54/slides/ieprep-sipping-joint.pp

[MAP] The above seems to be talking about the Call Control messages, not the 
media stream. Priority treatment (or drop procedures) for call control 
messages needs to be defined, but it is not the problem mentioned above.  If 
the setup (INVITE) is marked somehow for distinct priority treatment, the 
responses to that INVITE could use the same treatment. This is not 
"transferring the priority to the callee".

Media flow is a different case. In all discussions of priority services, it 
has been assumed that the originator of the call determines the priority 
level or treatment desired. If the level or treatment is allowed, it must 
apply to the media flow in both directions, so the callee must be given the 
"authorization" to send voice packets at the higher level. There is no case 
that I know of in which the choice of priority is also dependent on the 
capabilities of the called party.

I suppose one could define a service in which a call made by a regular caller 
becomes "priority" when it reaches the destination (e.g., call to a police 
station, not 911), but I don't believe there has been any suggestion for 
this. However, it would still need to affect media flow in both directions.

> Given the above and our tight deadlines, I am going to suggest we first

[MAP] I believe that consideration of "priority" of media stream packets must 
to included, where "priority" really refers to "preferential treatment" of 
one voice packet over another. For SIP (call control) messages, I believe 
that "priority" should also be considered, that is, preferential treatment of 
one type message over another.

The difficult part is the consideration of preferential treatment of voice 
packets vs SIP messages. But without consideration of this issue, we could 
end up with a perfect system that passes the voice packets for the high 
priority call over those of the low priority call, but is unable to pass the 
call setup messages to establish a new high priority call or to release an 
existing low one.

Granted, this final item is not something that SIPPING needs to directly deal 
with, but it needs to be considered in Requirements. Although the actual 
procedures to apply preferential treatment at the packet level are not in 
SIP, there may be a need to carry specific information in SIP to allow it to 
happen.

> Kimberly

Mike Pierce
Artel

---

From: [email-masked]
Date: Wed, 18 Sep 2002 23:51:51 EDT

In a message dated 9/18/2002 9:49:01 AM Eastern Standard Time, 
[email-masked] writes:

> [KSK] Let's imagine SIP proxies prioritize messages. Then this is what I
> mean by "transferring priority"...Imagine a high ranking official makes a
> "flash" call to a low ranking one. That high ranking official is authorized
> to send INVITES (and other messages) at "flash" level. Now the call setup
> in the other direction will also have SIP messages associated with it. But
> the low-ranking official isn't really authorized to make "flash" calls.
> Instead, the priority of the SIP messages that are sent, if they also are to
> be sent at "flash" must have been transferred by virtue of who was calling.
> We have just described the same thing. I called it transferring the
> priority to the callee and you called it "just use the same treatment". So,
> independent of what you call it, it is complicated.
> 

[MAP} I don't see how this is complicated. Some coments on the points in this 
paragraph, because I think they represent some fundamental different ideas.

First, I think we need to quickly agree that there can not be 
"prioritization" of messages or packets within a single flow. By this I mean 
that nothing can try to send one packet ahead of another, rather, they must 
be sent in the exact order received. A "flow" in this case would be all the 
SIP call control messages (in one direction) related to one call, or all the 
voice packets (in one direction) for one conversation. That's why I used the 
term "preferential treatments" in my draft.

Second, the "high ranking official" is not "authorized to send INVITES at 
flash level". They are authorized to setup a call at "flash level". As I have 
described in my draft, this might be implemented by marking the INVITE itself 
for some "higher priority" treatment than someone elses INVITE for a "Routine 
call". (This is exactly analagous to what is done in ISUP.) I don't see any 
need to "send the INVITE at Flash".

Correct, the low-ranking official isn't authorized to make "flash calls", nor 
are they trying to in this example. Their device is responding with the 
appropriate SIP response. It should be trivial to say that the response to an 
INVITE should be marked for the same preferential treatment as the INVITE. 
And it should be relatively easy to get the voice packets in the called to 
calling party direction properly marked for the required preferential 
treatment. This is a requirement.

In fact, if we figure out how to provide proper priority treatment to all SIP 
messages vs the media packets using the same path, there may not be any need 
at all to mark INVITEs for high priority calls any different than those for 
low priority calls.

Mike Pierce
Artel