Subject: [Sipping] Very rough notes, Tuesday AFTERNOON SIPPING meeting (Session 2)

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Jul 2002 08:13:15 -0500

Please review and feed me back comments for the minutes.

--
Dean

-------------------------------------
Notes, SIPPING Working Group, IETF 54, Session 2

Agenda: Rosenberg and Baker talks reversed due to availability

Markup and Application Interaction, Jonathan Rosenberg

  Slides review origin of user input problem with DTMF. Prior effort
  has focused on use of RFC2833 for in-band DTMF, but this requires
  media forking and doesn't work for a lot of apps. INFO has been used
  as an alternative, but this usage is undefined and
  non-standard. Key-events is a step in the right direction, but
  incomplete. This is really stimulus signaling, where the user is
  interacting with an application in the absence of a semantic
  understanding of the application on the part of the user agent. This
  lead to the "markup" draft, thence to the "app-session" draft,
  thence to a largely undefined scope problem . . . .

  Comment: There seems to bea at least one "energy barrier" here. If
  the user thinkjs he is talking to a correspondent communicator
  semantically like another person that is on one side of the barrier
  (voice mail). If the user is running an application where the normal
  things we do with SIP are just aspects of the application, like
  playin "wuake" where some parts are doing sideband talks and others
  are rendering location and others are doing movement vectors, etc --
  that is, there is a larger application orchestrating more than one
  sip session, then that's something else. We may not want to deal
  with these two categories in the same way.

  Comment: This second category is not the same as that identified in
  the "stimulus" model described above. Response: We think we've
  constrained it right in the current draft.
  
  Comment: Morphing a functional protocol into a stimulus protocol can
  make some things wierd. Really, we're taking requirements from a
  stimulus model and attempting to apply them in a functional model,
  and that risks some complexity. Maybe we want to do something
  quicker and easier to solve the basic DTMF problems. Response: Let's
  look at what it will take to do it right first. 

  Comment: Trying to deal with multiple applications concurrently will
  require a much stronger concept of focus than that required for a
  simple stimulus model.  We'l;l need to move there eventually.

  Comment: drowned out by chatter.

  Conclusion: We wish to propose a design team to tackle this. The one
  thing we seem to need to do is charge the design team with coming up
  with a solution quickly for the simpler problem class and "heading
  off" the info based systems soon is probably too critical to let
  slide. Poll takem on forming desigtn team met with string
  approval. Plea from audience: put interim findings out to list, not
  work in a vacuum. 

IEPREP, Rohan Mahy, Fred Baker, Henning Schulzrinne

  Rohan: We were asked by ADs to have joint meeting between SIPPING
  and IEPREP becauseSIP is being asked to do some things with respect
  to emergency preparedness. We'll start by describing the arch of SIP
  as is likely to be appropriate to IEPREP. Many people think of SIP
  as a telecom protocol, but it's really an internet protocol with a
  different role for intermediaries. Most intenret SIP proxies provide
  message routing functions, but not QoS and other really stateful
  functions. The main things in the SIP architecture are the user
  agents -- gateways, ordinary phones, and application platforms like
  media servers. These are responsibile for "doing the right thing"
  with requests. If they need to pre-empt focus, or route a request
  into a priority queue, or request a special QoS, thenm that's what
  they do. They MAY use other elements to do these things, but have
  the essential responsibility. Clarification question from Henning:
  Are we assuming that proxies may nor may not drop call requests?
  Answer: Yes. Proxies tend to drop stuff when overloaded, and may use
  this as a mechanism for policy or congestion, etc. Comment, Oran:
  Proxies have to be DOS resistent. If they are, then they've fixed
  this problem to some degree.

  Fred: Start with big picture, then go into Henning requirement's and
  Dennis' telco perspective. Slides review making of calls in a hybrid
  environment, with the question being "What happens when you place a
  call?" Imagine we've had a disaster -- everybody picks up the
  phone. Most of us are just in the way, and we need those who can
  actually help to get through. There are policies such as MLPP which
  detail a prioritization scheme based on rank, etc. How does this
  work? When a call comes in from a PSTN, we'd like to be able to
  place that to an IP telephone, or in from an IP telephone, out to an
  IP phone or PSTN or whatever as appropriate. We must have
  information that allows us to classify the call within the policy
  schema. Example given of incoming call preemption. In the MLPP case,
  the call is simply preempted and replaced. For IP devices, we need
  to have some way to tell the device that the pending call is higher
  priority than the current call. This has nothing to do with the
  location of the SIP proxies, which could be anywhere.  With IP, we
  also have the problem of making sure that the important calls get
  the needed bandwidth if it happens to be scarce. This probably
  becomes something in RSVP or something like that. Three
  requirements: We need to "bypass" a busy singal, have a policy for
  admission and bandwidth allocation, and exchange such values
  transparently with PSTN. This requires one-to-one mapping with PSTN
  representations to provide for call tunneling cases.

  Rohan: The intent is for this work to become a requirements document
  from IEPREP to SIPPING. The current work is light on security and
  privacy requirements , and the following presentation will raise
  some.

  Henning: We will discuss security requirements for SIP-to-PSTN for
  access top PSTN resources. Key is end-to-end strong authentication
  and authorization. This depends not just on rank, but on role and
  criticality of the specific call in question. The risk here is not
  just fraud, but disruption of the performance of the overall system.
  It is likely that intermediary nodes may need to participate in
  authentication/authorization roles, especially in delegatory
  models. In general we need to authorize any assertion of priority,
  not just assertion of identity (a given individual may make higher
  or lower priority calls). This is a classic cross-domain problem --
  the principal may be in a different domain, and may not be able to
  rely on local-domain authentication protocols such as kerberos. We
  must also make minimal requirements on the capabilities of a given
  device. For example, the party may be using an ordinary civilian
  phone to try and deal with a major emergency. Question: How does
  this work from PSTN? Answer: In civilian world, user dials a special
  area code and PIN, requiring participation from the local
  carrier. Mil phones may have special buttons. The privacy
  requirementgs are also interesting -- for example, leakage of
  identities of parties in high-priority calls may leak strategic
  planning information, such as which ship is being launched. Other
  open potential requirements include 1) priority-sensitive routing
  vs. explicit routing through priority nodes 2) avoiding two stage
  dialing, and 3) discovering namesapces (which may have seperate
  authentication concerns). Comment: Unstated metarequirement. Systems
  like this need ways of being invoked regularly outside of "real"
  emergencies, inlcuding full systems exercise, or the systems will
  not work when actually needed. What do we assume about IP network?
  Is it a custom built network, any network with a specific set of SIP
  devices (major firewall issues), or "any public network, any public
  device"? Clarification point: MLPP is an ITU standard and there also
  numerous national standards in PSTN. Comment: The "any public phone"
  scenario may actually be very critical. Process note: This is just a
  preview of the requirements document, but the final version is still
  being worked in IEPREP. We need to make sure that our feedback thru
  IEPREP is requirements based, not solutions. Need also to make sure
  that the SIP people do not ignoire IEPREP and that IEPREP doesn't
  make too many assumptions. 

  Closing questions: Question? Is the general 911 call in
  IEPREP's charter? Not yet, but then 911 is also not chartered in
  SIPPING. On the other hand, IEPREP expects that they will deal with
  all aspects of preferential calls. Comment: Reader did not notice
  anything about speech codecs in requirements. We need to make sure
  that "launch" does not sound like "lunch". Comment: In problem
  statement, what are requirements for location specific information,
  and how will this relate to geopriv? Fred: yes, maybe, depending on
  specific circumstance. Comment: Are we developing requirements on
  manageing diversity, redundancy, etc. One view is that this is
  system architecture and implementation, and therefore out of
  scope. It might be reasonable for us to build an informational model
  of how one might wish to build. A second position is that there may
  be requirements that mandate reserved facilities, but that this is
  still out of scope for SIP/SIPPING. Comment: The requirements can
  really be dividied into originating and terminating sides -- the
  general ordering a launch versus n-many calling the fire
  depertment. Answer: this is a question of the relative authorization
  levels, and it might be that 911 calls get bumped or
  vice-versa. Conclusion: We're really looking for something like
  call-waiting with policy and a formalization for the specification
  of that policy. We're supposed to be dome with IEPREP requirements
  this week, or if not very soon.

_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 17 Jul 2002 07:24:48 +0100

For the joint discussion on SIPPING and IEPREP:

I thought at the end of the meeting we ended up with the conclusion that emergency calls (for the regionally challenged read 911 calls) were an orthogonal issue to that of the international emergency preference service. As a result, rechartering of SIPPING could be discussed to include Henning's drafts, and Henning's drafts did not need to go to IEPREP. Of course if someone really wants resource priority on an emergency call, then that would go to IEPREP, but that is not the subject of Hennings drafts at the moment.

There was also an equivalent discussion of the interaction of GEOPRIV and IEPREP, where again I think the answer was that they are orthogonal problems - it is possible to have IEPREP calls that need GEOPRIV, but each group deals with its own requirements.

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 16 July 2002 14:13
> To: [email-masked]
> Subject: [Sipping] Very rough notes, Tuesday AFTERNOON SIPPING meeting
> (Session 2)
> 
> 
>