AC's Notes on SIPPING Session 2, IETF 57
SIPPING Session II, Thursday, July 17, 2003, 1300-1500
1) Agenda/Review:
Gonzalo Camarillo asked the group to review Digest-AKA and
get back to the authors.
2) Open Issues from Application
Interaction Design Team
draft-rosenberg-sipping-app-interaction-framework-00
draft-jennings-sip-app-info-01
draft-burger-sipping-kpml-02
Presenter: Jonathan Rosenberg
Issues:
KPML DTMF reporting problem
·
INFO
o Cannot work within call dialog
·
NOTIFY w implicit subscription
·
Explicit subscription from
application
·
HTTP
·
New method?
·
MESSAGE
Design team reluctantly chose MESSAGE!
Proposal:
·
Continue to hammer out the open issue
·
Adopt the framework and KPML as
SIPPING items.
Conclusions:
a) Hum on “This is interesting work and that
we should adopt the framework” – Accepted.
b) Hum on “All who believe KPML should be
accepted as WI” – accepted.
c) Chairs will ask the AD to adopt framework
and KPML as WG items.
d) The KPML reporting issue will be discussed
more on the mailing list.
3) Discussion of Media-related Issues
3a) Early media
(draft-camarillo-sipping-early-media-02.txt):
Presenter: Gonzallo Camarillo
Changes:
·
Clarify which features are specific
to early media and which ones to SIP and other editorial changes.
To be done:
·
Align application server model
section with app design team
3b) Conveying Tones in SIP (draft-mahy-sipping-tones-00.txt)
Presenter: Rohan Mahy
·
How to provide tones?
o
In RTP
§
Speech codec – poor choice
§
Using audio/tone AVT payload
§
Using audio/telephone-event AVT
payload
o
Referenced externally by URI with
Alert-info or message/external
o
In a SIP header (proposed back in
Nov 2000)
o
In the session description?
o
In SIP body
§
Content-Disposition: Render
What body types are available:
·
Traditional
o
Wav, au, mp3
·
Audio/tone
·
Audio/tone-info+xml
·
Many more…
XML based:
Audio/tone-info+xml
Discussions:
-Use of midi was suggested by Henning.
Conclusions:
a) The issue on tones will be discussed more
on the list
3c) Network Announcements (draft-burger-sipping-netann-06)
Issues:
·
Early media
o
Punt. No definitions for early media
o
Makes 487/409 problem go away.
·
Media on hold
o
Punt. Local matter
·
Multiple media streams
o
Punt. Netann is about objects not
streams
o
Only composite objects for multimedia
·
VoiceXML keyword without value
o
Generate 404 with explanation.
Discussions:
-No comments.
Conclusions:
a) The draft will be submitted for
publication as an individual contribution.
4) Discussion of Event Filtering and Throttling
(draft-niemi-sipping-event-throttle-reqs-01.txt)
Presenter: Aki Niemi
Changes:
·
Updated model
o
A throttle defines minimum time
period between two notifications
·
Updated use cases
·
Refined requirements
o
Aligned language with model
Open issues:
·
Should use cases be more elaborate
o
Proposal No
·
Requirements are solid enough
·
Scope for work is well defined
Next steps:
·
Move to WG item?
Discussions:
-
It was suggested that it would be
worth noting in the draft about the type of buffering needed (like
LIFO, FIFO etc)
Conclusions:
a) It will be recommended to the ADs to adopt
this draft as WG item.
5) Discussion of DPNSS to SIP interworking
(draft-mukundan-sipping-dpnss-02.txt)
Presenter: Ranjith Mukundan
Difference between DPNSS MIME and QSIG/ISUP MIME
·
Similar to RFC 3204 (MIME for
ISUP/QSIG
·
Mandates single binary coded octet
message length field
·
Specifies message buffering option
·
Mandates single DPNSS call per SIP
dialog
Discussions:
- Henning indicated that this doesn’t work with the MIME model.
- Some were skeptical about the usefulness of doing this work.
- There was a feeling that the group did not have enough expertise to
take on this work.
- Gonzallo indicated that solving the MIME type is reasonable but the
translation work is a tough thing to do.
Conclusions:
a) This will NOT be taken as WG item and it
will proceed as an individual contribution.
6) Discussion of End-to-middle Security
(draft-ono-sipping-end-middle-security-00.txt)
Presenter: Kumiko Ono
·
End-to-end encryption may conflict
with some features provided by intermediaries
·
Use cases:
o
Logging services (IM logging, other
logging)
o
Hotspot service
§
Connecting to home SIP server via
partially trusted proxy
o
Session-policy
o
Transcoding
Proposed Mechanism:
·
Allows a UA to disclose data to
selected intermediaries
·
End-to-middle encryption uses S/MIME
CMS Enveloped data for intermediaries.
Discussions:
-
People felt that this is a very
interesting WI.
-
Jonathan R said that we need to add
more use cases to explain the problem of addressing data for
intermediaries by user-agent.
Conclusions:
a) There was consensus in the room that work
has enough interest in the group.
b) There was consensus that the requirements
on end-to-middle & middle-to-end security should to be taken on as
WG item.
7) Discussion on Phone-related Status and Presence
(draft-rosenberg-peterson-simple-pidf-phone)
Presenter: Jonathan Rosenberg
What is it:
·
A set of presence states that
describe a phone as an application
o
Considered black phones, wireless,
enterprise
·
States are things like in/out of
call, registered, call waiting
·
Looking for comments and inputs to
this work.
Discussions:
-Difference between human presence vs device presence.
- Rohan said that states like dialing/ringing etc are not applicable to
device or user; these are particular to a call/dialog. Some of the raw
data is useful, but presence may not be right place for it.
- Henning: Information like line-state etc are not too useful as
presence information.
Conclusions:
a) Hum on “Dealing with presence issues of
phone” - Accepted.
b) Jonathan proposed to develop more use
cases for the draft.
c) Is this a SIMPLE or SIPPING activity?
8) Discussion of Diagnostics in SIP
(draft-johnston-sipping-rtcp-summary-00.txt)
Presenter: Alan Johnston
- Delivery of RTCP summary reports to
third parties
- Logging is main motivation
- Three alternatives
- Forking RTCP to multiple locations
- Carrying in SIP header in BYE
- Event package (preferred)
Discussions:
- Should RTCP be transferred to third parties?
- Jonathan R: What is the purpose of this? If this is for
fault management or performance management, this is not needed. SNMP
management
tools should be sufficient.
- Eric burger: This is definitely an SNMP kind of thing. Now
we have SNMP over SIP; so, when will this stop?
Conclusions:
a) This will be deferred to this to
the list.