Subject: [Sipping] Notes, Session1

From: "Dean Willis" <[email-masked]>
Date: Mon, 18 Mar 2002 12:57:30 -0600

The following are my rough notes from the first SIPPING session. Please
report any inaccuracies or needed additional inclusions to me as soon as
possible.

-------------
Meeting Notes, SIPPING Session 1, IETF 53 18Mar02

Chairs announce "Note Well" 2026 provisions.

Agenda Bash:  

No Comments

Status:

* SIP-T and ISUO-SIP -- ready to resubmit after blackout

* SIP Overlap Dialing -- shjould be ready for WGLC next month.

* Requirements for Deaf -- Hum on objections, none noted, will move to
last call.

* E164 and ENUM to discuss in ENUM WG

* cc-transfer -- depends on refer, replaces, has security concerns

* Fax -- new comments from ITU from group review, informal liason
reported, formal channels  expected to be exercised soon. ITU has
essentially combined and cleaned up T.38. They want  to reference this
doc, and are happy with it being a a BCP instead of informational. They
wish to further request collaboration and notification of changes. They
also suggest  splitting fax and modem into two seperate documents.

* Call Flows BCP -- needs updates to torture tests, do we need some
bis-specific torture  tests? We also need volunteers for formal review
on a section-by-section basis, target WGLC  for last of May.

Service Examples Draft, Alan Johnston:

* Updated for bis in this release. 

* Open issues with getting setup info for transfers, etc. Suggest doing
the development of  the SIP events package proposed in
draft-rosenberg-sip-call-package. 

* Several issues with Replaces resolved, especially around transfer of
call. Main one is use  of Require: replaces to verify capability of
foreign node.

* Join: Some primitive with a function like the draft-mahy-join-and-fork
"Join" header  required to complete single-line-extension.

* Caller Prefs: How should we demonstrate this stuff in call flows?

Multiparty Apps Framework Discussion, Rohan Mahy:

* The "new" cc-framework is an attempt to bring together categories and
descriptions and  working groups status of various drafts across SIP,
SIPPING, and individual contributions.

* Question to group: Is this approach "what we are looking for". General
response seems  favorable, and the document editor will proceed.

Conferencing Requirements, Orit Levin and Henning Schulzrinne:

draft-levin-sip-for-video: Objectives are a BCP guide for building
"multimedia" conferencing  apps, with similar user interface and clear
migration path from voice-only connections using  basic non-extended SIP
UAs. 

Stuff in many WGs:
* Call control in SIPPING
* Capabilities exchange/declaration in MMUSIC
* T.120 and other app integration in MMUSIC
* Media control in AVT
* Conferencing and Floor Control models in SIPPING/SIP

Media Control is viewed as critical open issue. Where should work be
done? 

Comment from audience: Sounds like exactly the original charter of the
MMUSIC working group.   Only difference is requirement that simple SIP
client be able to participate in session.  Also suggestion that "control
channel" is just another media in the session, and should be  treated as
such by the system. 

Comment from audience: The control channel is sort of like but not
completely like media. 

Suggested approach: do a frmwawork draft, maps requirements to solutions
using existing  drafts andapproaches as possible, slosely related to
multi-party application framework.

Question from audience: presumes certain boundary around "what a
conferencing application  is", presumably from classic conferncing
model. What about other approaches, such as  collaborative editing
models? 

Requirements for Conference COntrol, Henning Schulzrinne: Suggest focus
on media-independent  control for range of conference models with core
property of single "media choke point".  Functional taxonomy presented
in slides. List of floor control primitives in slides.

Comment from audience: Group membership management is very similar to
authorization policy  for subscription in Events structure. 

This problem space seems to have commonalities with SIP: asynchronous
event functions and  synchronous command functions to "the conference"
(as opposed to commands to participants).

Work division model proposed in slides. 

Comments from audience: 

* Shouldn't split asnychronous events from synchronous commands. 

* This work spans a lot of groups but isn't in any specific one.

* Must make efforts to mesh well across many groups

* Missing something in the problem statement: We have not addressed of
graph building,  leaving us with star and mesh, neither of which scales.
Media transmission along a graph is  something we're not treating well.
Once we can do that, if can think about contolling and  eventing along
the graph. Suggestion we decide the problem along these lines.

-- Response: This is a big effort. With the scoping suggested, we have a
constituency. Don't  want to repeat the last 10 years of MMUSIC.

* Request to get decision on work plan made soon.

Chair position: There is clearly interest. We have to work out issues of
scope and  jurisdiction.

Request History Rerquirements, Mary Barnes:

Several examples presented of SIP call diagrams in which there may not
be enough information  in current SIP to make appropriate state analyses
in various nodes.

Issues from mailing list discussed in slides. 

Comments:

* the general problem is not one of information loss. Propagating
information upstream is  oen of the problems. The second piece is
"telling someone why they got a request". this is  much more like caller
pref sand identity issues.

* need to decide when to throw information away.

* may be important problem here, but where? we're getting into the
identity issue again. We  should work on this and try to find general
problem. there is a profound slippery slope  problem.

* discussion that there is a big differendce between the lack of
information at a random  proxy, and the failure of a 

* It's the systems that manage identities, not the endpoints, that need
to have knowledge.

* Need to clearly delineate between "what happened to the request" and
"what you want the  next hop to do". 

Hum for continue working: loud. Open issue with spllitting it into two
pieces.

SIP Telephony Device Requirements, Dan Petrie:

tries to formulate requirements for phone-like devices on fixed and
wireless (not 3G)  networks. Includes requirements for device
conifguration.

Splits issues:

1) Configuration discovery -- maybe inside of SIP?
2) UA enrollment -- inside of SIP
3) Confiuration retreival -- outside of SIP
4) Configuration change notification -- may be SIP?
5) conifguration change upload (phone to server0 -- outside of sip

Discussion: Use of SIP for configuration discovery and change
notification. Comment from  audience: seems to be a lack of
understanding and analysis of other protocols for doing  this. Plea for
simplifying the administrator role by reducing number of configuration
mechanisms. Comment: Didn't we decide not to do this two years ago? What
has changed? Ans.  We have now clarified between data transfer (not SIP)
and SIP identity-related discovery and  notification issues. Comment:
there has been some analysis of SNMP as not adequate. Comment  from AD:
there ARE other conifguration protocols. This would be a very hard sell.
chair  action: defer to list. Hum for in/out of scope slightly weighted
towards in scope.

Tel: URL enhancement work, Jon Peterson

Work is probably moving to iptel group. Please read rfc2806 bis and
comment ASAP.

Emergency Services discussion, Henning Schulzrinne, Mike Pierce:

SIP Resource Priority, Henning Schulzrinne: Establish priority when
competing for  terminating UA resources. This is not "network priority",
more like an SMTP priority flag.  Open issue: Do we need an Accept tag? 

Comment: IEPREP group is working on requirements. We should hold up
priority header until  IEPREP has considered more requirements. At least
we should let IEPREP look at it and see if  it applies.

Comment: There are probably privacy and security requirements for use of
this header needed  to prevent SPAM. Security requirements in draft are
probably not adequate.

Comment: Needs to be discussion of WHO will be looking at this header.

SOS, Henning Schulzrinne: 

Issue on IANA considerations for reserving names such as "SOS@domain". 

Comment: happy to have a BCP saying "SOS is a reserved word" but this is
not a solution for  e911 and we have to be carefult that this is
understood.

Comment: We should use MAYDAY or PANPAN instead of SOS.

User Application Control:  Bert Culpepper:

Assumptions and requirements given in slides. 

Open issues:

1) What should the mechanism be: Is it SIP?

2) IS SIP Events framework appropriate?

3) If so, what should payload format be?

Comment: If we require people to suscribe, we need to tell them WHERE to
subscribe

Comment: Would like to express higher-level semantics than just key
scan-codes. For example  "jump left three feet and shoot" instead of
"4,4,4,5"

Comment: This is much more like a markup problem. Maybe we could provide
a stanadard DTD for  keys, or perhaps dynamically loaded for custom
mappings.

Comment: Is a stop-and-wait protcol adequate?

Comment: Mechanism should be more extensible than just keys, but this is
a good starting  point.

Comment: We don't want to reinvent X or VNC.

Comment: Two sets of requirements: delivery, and content. These should
be dealt with  seperately. 

Comment: Previous questioner asserted difficulty with knowing semantics,
but a markup  approach could solve this.

Comment: There may not be a human at the UA, so if you don't have
semantic awareness at the  UA, you prevent useful interaction.

Comment: Current model of markup does not solve twoi-directional
question of "what the  device possesses" as well as the "what are the
semantics".

Chairs: hum for interest? High level of general interested indicated.
Feed changes in  requirements into Bert.

PUBLISH Requirements, Robert Sparks:

Covers Donovan's requirements draft. Slides review requirements from
Donovan draft. Review  Stucker draft proposing solution to those
requirements. Presents discussion of requirements  abstracted from
protocol proposals 1) Binding to SIP identities, and 2) Getting the
information to the node responsible for the application associated with
the SIP identity.

Question: Do we agree we need to meet these requirements?

Comment: Calling it a "publish" mechanism is semantically leading and
should be avoided.

Comment: What are the kind of issues that would help us decide whether
this needs/not to be  SIP. Is it a single server or a server farm? Does
it need to be reliably available to more  than one place? Comment" this
is same as REGISTER problem.

Comment: Sceptical if there is such a thing as a "generic upload
requirement". Generally,  this is more like an operation against a
network object. This is consistent with SOAP or  RPC.

Comment: We should look at what we know, determine the specific
requirements, and go from  there.

Comment: Whether stuff uploaded is merged with an application orused
en-bloc is up to the  application, but a generic mechanism should be
doable.

_______________________________________________
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