Subject: [Sipping] Comments on draft-peterson-sipping-ieprep-00

From: "Gunn, Janet" <[email-masked]>
Date: Tue, 11 Mar 2003 18:22:18 -0500

My personal (not representing any organization) comments on
draft-peterson-sipping-ieprep-00

Some of these comments address details rather than the overall sense, but I
think it is important to keep even the details straight.

Section 2-2 Signaling Encapsulation

"In the CSN, it is not possible to
      make an emergency call, for example, from France to the United
      States.  International ISUP gateways that bridge between different
      signaling systems will at best discard priority information."

Actually, it IS possible.  Every month over 3000 GETS (710...) calls are
placed from over 50 international locations.  They receive no priority until
they get to  US based switch, but most of them DO  receive priority
treatment within the US.  Granted, it is the "710" that is passing through
the international gateway, but that IS a "priority label" as well as a
dialed number, and is not "discarded by the international gateway".

"It's not clear that it would even be desirable for priority
      information to be retained when you cross network boundaries - if
      someone's a government official in Iraq, when they place a call to
      the United States, should they be afforded the status of a
      government official here?"

Just as with the ISUP "Precedence" parameter, the priority information
could/should indicate (or be mappable to) the context within which it
applies.

Also, the NCS is actively working within the ITU-T to set aside an
international CPC so calls may be recognized as emergency or priority at
international gateways.  The issue of determining which countries should
receive priority is recognized, and messy. 

"Some additional discussion is necessary to understand why signaling
   encapsulation is insufficient for CSN-IP-CSN architectures.  If this
   amounts only to the requirement described in Section 7, then
   signaling encapsulation may still provide some useful properties to
   the terminating gateway."

Signaling encapsulation definitely DOES provide "some useful properties".
But, as you noted above, it does not allow for making "different routing
decisions for some calls in the presence of a priority indicator".

Sec 2.3  ETS in existing SIP networks

"This points to a fundamental questions: Is ETS opt-in?"

Personally, I think it is reasonable to expect that ETS will be "opt-in" for
the most part, at least in terms of providing any kind of special services.
But I think it is also reasonable to hope that "transparent" networks will
pass the priority information (directly or encapsulated) even if they do not
DO anything with it.  Similarly, I want to make it as easy as possible for a
network to make the decision to opt-in.

"and even then,
   there is no guarantee that fully compliant implementations will be
   ubiquitously deployed, nor configured to behave appropriately in an
   ETS situation."

This is true, even in the current CSN, and has not precluded the
implementation of  a useful, near ubiquitous, service.

"...only networks that develop relationships with the
   relevant government agencies, and are given proper configuration
   information by those agencies, will do so."

True, but the hope is to make it as painless as possible for networks to
develop those relationships.

3.1 General Requirements

REQ-4 "The 'mapping of schemes' requirement could be taken to be
   strong or weak." 

 I had interpreted it as "weak", in some ways analogous to the ISUP
Precedence parameter.

REQ-7
(wrt MLPP in the CSN) "It's never unclear within a certain network
   how a given element will behave when presented with a prioritization
   indicator."

Unfortunately, this is not true.  The standards dictate what SHOULD happen,
but the actual implementation often does not reflect the standards.

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Mar 2003 19:42:08 -0500

To amplify what Janet wrote: I think Jon's draft misses the point that 
we want

- networks that don't want to play to at least not get in the way (i.e., 
not prevent delivery of services downstream)

- require minimal changes to end systems

- support non-ISUP originators (e.g., SIP soft-terminals)

It's a nice side benefit if 'joining' ETS is easy, but the primary 
consideration is that needs it work with standards-compliant SIP 
elements (in particular, proxies) that are unaware of it.

It should also have the "earliest possible" property, i.e., as the 
network becomes ETS-aware, suitable treatment gets applied closer to the 
caller.

Thus, success is not measured by whether we get 100% coverage or 
international coverage, but rather whether I can plug in a SIP terminal 
or use my laptop and get whatever service I can.

One could clearly model the SIP solution on the GETS system, by having a 
"gateway" with a specific SIP address (equivalent to the 710 number), 
which then prompts for another SIP address or tel URI. From scaling and 
architectural perspectives, this seems much worse.

The draft tries to make this clear by emphasizing the different network 
types.