Notes, SIP WG Interim, May 2002, Day One, Afternoon

Reporetd by Dean Willis and Brian Rosen

Minutes of SIP/SIPPING Interim Meeting
May 6, 2002
Afternoon Session
Reported by Dean Willis

Call and Conference Packages -- Jonathan Rosenberg leading discussion:
  Dialog Package has open questions on scope of data
  conveyed. Question from audience: What do we really need? What is
  the use case, and how do we keep from just ending up with an XML
  representation of the whole SIP message? Argument can be made that
  most of the proposed information would not be commonly used. Main
  use case is for replacing (or identifying, for join, use indicator
  etc.) a dialog that someone else has, as in call park, auto-callback
  and single line extension apps. This is NOT intended to reflect the
  content of every SIP message, just to reflect status of dialog
  participation. One suggestion is to follow state transitions of the
  related dialog state machine. Assumption: This reflects only dialogs
  initiated by INVITE messages. Room polled for consensus on this
  assumption with strong consensus reported. Comment: This information
  is potentially highly sensitive and calls for very strong statements
  on authentication and authorization. Proposal: SDP and related stuff
  removed from next rev, dialog initiation on state machine.
  Suggestion that it would be nice to know whether there is or is not
  an active media stream. This led to an extended conversation of the
  concept of a "hold" state is meaningful or one should have seperate
  event packages for media-session monitoring. Poll taken, no media to
  be included in dialog package. 
  Conference package: Currently contains status of participants and
  their activity of sending or receiving. Prveious release also had
  floor control. Question: How do we scope this? What are the
  immediate applications? Could this be applied to a cascaded
  conferences so that "conversation" membership information spans
  multiple "conferences"? This led to an extended discussion on
  mechanisms and rationale. Two consensus points: 1) It is interesting
  for a conference particpants to know what other participants there
  is a direct dialog relationship with. 2) It is interesting for a
  conversation participant to know who else is participating in the
  conversation. Note: Neither of thise cases mandatory. Proposal:
  Should would do this with a seperate conversation info package?
  Conclusion: will proceed with conference info and investigate
  conversation info alterntative and see if it works as seperate
  packages. Suggestion: It would be interesting for a conference
  moderator to know which participants are hidden and which are
  "robots". Media issue: Does floor control require media awareness,
  or just a token of "who can send now"? Note: It would be useful to
  have a correlation between the RTP CNAME and the associated SIP URL.
Request History Requirements -- Mary Barnes leading discussion
  Requirements slightly modified in current -01 version of draft. Note
  that it appears anything solving these requirements would solve the
  3GPP "called user ID" problem. Question: Do we really need to store
  the "new" request URI at each retargeting operation? Whoa, what
  happens when we fork? Question on requirement to be able to notify
  dialog initiator of retargetting operation: does the imply a NOTIFY,
  and if so, how is subscription handled? Alternative might be to
  return retargetting code in a 100-class message. Question on scope:
  this shouldn't be used to determine next-hop routing, like "which
  voice mail box to route to based on previous retargetting reason".
  A repeat of the 3087 "explicit forward knowledge" vs. ISDN "explicit
  reverse knowledge" forwarding models ensued. Suggestion that we need
  to really consider security and privacy requirements -- for example,
  retargetting names or reasons might reveal otherwise confidential
  status information or names used for personal routing.

Reported by Brian Rosen:

Eric Burger discussed URIs as Service Indicators. He differentiated between applications services, which needed responses on the order of 300-500 ms from network services, which might need 1-20 ms response. He wants to differentiate based on whether there was subscriber data required to fulfill the requirement. There was not unanimous agreement on this differentiation. Rohan wants well known defaults to make interoperable systems.

URI conventions seemed harmless. Eric observed that his prior work was criticized as being too specific. Now we are complaining he is too broad. Allison worried about the general applications area, and work done in other groups. SIP should not define a new application discovery/naming convention/... scheme. Eric will rework it.

Ben Campbell presented pub-bind-reqs. Wants to keep this strictly associated with an AoR (multiple services associated with a single AoR), thus may be like event header. Really just provisioning. Assume URI addressing. Pub URIs may be in a different domain from service URI. Need a lifespan management.

Probably needs multiple protocols to publish.

Read the draft!

updated 08 May 2002 19:19 -0500