Rough notes reported by Tom Taylor. Due for revision soon.
Session 1: 6Aug01 0900-1130, King's Suite/Balmoral 2
1. Proposed Agenda ====================
0900 Agenda Bash -- Chairs 0910 Status Review -- Chairs 0920 Last Call Process and Report -- Chairs 0930 Call Control Extensions draft-biggs-sip-replaces-01.txt -- Billy Biggs Robert Sparks standing in for Billy draft-ietf-sip-refer-00.txt -- Robert Sparks 1000 Events (Two Issues) draft-ietf-sip-events-00.txt -- Adam Roach 1030 Early Media Extensions draft-sen-sip-earlymedia-00.txt -- Jayshree Bharatia draft-rosenberg-sip-early-media-00.txt -- Jonathan Rosenberg 1100 SIP and NAT Extensions draft-boer-sip-src-00.txt -- Michel de Boer draft-rosenberg-sip-entfw-02.txt -- Jonathan Rosenberg 1120 Changes in Session Timer -- Jonathan Rosenberg 1130 break Note: Any additional time will be used to start 2543bis issues
Accepted.
Bar BOFs
Proposed topics: Security 2200 Wednesday -- incl NAT & firewall traversal? Privacy Last Call Process NAT & firewall traversal Outbound services from remote proxy (source routing) Thursday evening
General disposition agreed -- notices to follow
2. Last Call Process and Status ========================
a. Last Call process: (Dean, charts) -- noted before that work was lagging -- Rakesh Shah assigned manager -- reviewed steps in process -- just starting to execute the process
b. Reviewed status of the various WG drafts in the light of the process. (Should copy from charts into minutes) -- SIPPING charter still under discussion, so WG docs included in this review. -- Will have to rename about 51 I-Ds when charter goes through
c. Comparison: charter and milestones
A-D pointed out Privacy & Security Reqts has to be dealt with at WG level, not in bar BOF. Will be factored into second session agenda.
3. Call Control ==============
a. REFER ---------------- draft-ietf-sip-refer-00.txt didn't make it into process in time -- available on supplementary site, will be submitted as soon as embargo lifts.
Open issues/bugs: -- should Referred-By be Remote-Party-ID or reuse it? Current Referred-By authentication mechanism may not be appropriate given other work in area.
-- David O: Remote-Party-ID provides service provider's view of caller identity. Not appropriate for Referred-By, but syntax may be reusable.
-- Michael T. Another example of need for generalized mechanism for message integrity
Question: pull out the security for consolidated effort? Michael T.: yes. In view of lack of dissent, Robert will pull out signature portion of work.
-- Event:refer body type should be message/sip. Does this work without reproducing excessive (leaking info) amt of message?
-- Jonathan: use a different message type message/xxx. Wonders if people interested in merging this with his draft on getting information on a call leg (call-leg event package).
Lack of maturity of Jonathan's proposal is sticking point. Bill Marshall concerned about third parties getting access to call-ID and using it to hang up call (DOS attack)
Henning: overlap of info between the two packages definitely a concern Rohan Mahy: Bill Marshall's point valid, but shouldn't apply stricter security standard to new work than protocol supports now.
Jonathan: use XML, one of the drafts as standard, other becomes delta Dave O: lot of people waiting for REFER for call transfer. May be able to solve Jonathan's problem by subscribing to specific messages.
Jonathan: accepts need to keep REFER simple -- no XML Robert: what about idea of putting Event header into REFER request? Adam: nortes subscription already getting abused. Henning: uphold principle: try to be explicit in what we do.
To list.
b. Replaces: ---------------------- No large changes. Relies on tags rather than full From: and To: headers to identify call leg.
No discussion.
3. Events (Adam Roach) ===================== DoS Attacks
Problem: SUBSCRIBE in, RESPONSE plus NOTIFY out = amplifier. Adam had not noted any discussion. Henning pointed to list discussion with challenge-response solution. Suggested need for general mechanism of anonymous authentification to ensure this is a real request.
Jonathan: noted limitation -- possibility of capture of authentification info. Henning suggests mechanism should go into bis draft rather than (as Adam proposes) the security section of the Events draft.
Jonathan suggests documenting general principles rather than specific authentification mechanism in something like the bis draft.
Henning proposes t5hat all drafts with amplification issue should point to need for authentification even if party identity not an issue, to protect against DOS attacks.
Problem: no technical problems preclude forking of SUBSCRIBE requests. Some philosophical objections. Proposes leaving general mechanism, but let individual drafts allow/disallow.
Jonathan: problems with ambiguity in interpretation of Record-Route when used as proposed in draft. Agreement: will provide explicit directions on how to handle backwards rRecord-Routing in draft.
Issue: interpretation of Expires: header. Was being used to indicate when subscription expires. Proposal: use new header Subscription-Expires including reason -- helps in migration of subscriptions. Neither supported nor opposed. Jonathan recalled alternative was more complex mechanism. Taken as limited support of proposal.
Issue: call-leg correlation: some wobbling on whether there be distinction between subscriptions initiated within or outside an existing call-leg.
Rohan: reqt is correlation between a notification and a specific call. Proposed: remove prohibition on mapping between notification and specific call. Jonathan: make sure semantics unchanged between cases.
Package name syntax: problem with syntactic ambiguity caused by private name spaces. Proposed to drop private name spaces. Henning: problem leading to this proposal is that once something has one name, can't change it -- but may want to migrate from private to public.
IANA registration the basic method. Concern that need ability to provide a name quickly (e.g. for development, testing) without being held up by process. Henning: as soon as interest in a given name is recognized, register it to prevent collisions. Out of time: to list.
Complete state vs. sub-state: currently recommend (SHOULD) complete state to be sent. Proposals to reduce message sizes by sending deltas of state after initial response. Suggestion to use versioning of bodies in deltas to detect missing info. (Proposed to be added as alternative.)
Henning note: delta encoding will be highly context-dependent. Jonathan would like discussion of deltas in main draft. Agreed.
Main changes since last draft: new section details info to appear in event packages. Added concept of sub-packages, incl supporting syntax changes. Added IANA Considerations section. (Brief discussion of whether it is IANA or ICANN issue)
Jonathan: apparently every open issue closed except package name syntax. Can't we finish it off? IANA: Dean asks what prevents name squatting. Answer: IANA run by people with intelligence -- check back. Lawrence Conroy: really uncomfortable with prohibition on private name spaces -- looked to IP example. Jonathan not sure it's a real problem -- just a programmer's issue. Allison concerned with extent of disagreement here. Noted that there will be a dialogue with IANA on what is feasible. No point in trying to fiunish here.
[Noted that although concept works for Megaco & MGCP packages, IESG has concern that package creation process in these cases is out of control.]
To list for initial position to go to IANA.
4. Early Media ================
a. draft-sen-sip-earlymedia-00.txt (Jayshree Bharatia) -------------------------------------------------------------------------------- Reviewed definition (pre-200 media flows), reasons why required when interworking with the PSTN.
Draft assumes unidirectional early media flow, callee to caller. Assumes use of manyfolks-..-resources draft.
Issues: -- change in address for media between initial 18x and 200 OK -- re-reservation of resources need when addresses change -- potential security loopholes because pinholes have to be opened without full knowledge -- misuse of SDP in 18x to indicate whether early media is expected
Jonathan: maintains that first issue not valid in case of announcement server -- changes call-leg. Port 0 to indicate reversion to local ringback: action on Jayshree to provide current 2543bis refernece
Scenarios -- call flows shown: (1) Gateway cannot determine from ACM whether early media coming (2) Can determine
Forking issues (1) Parallel -- potential race conditions (2) Sequential: may need sequential playout
Proposes strategies for non-forking, parallel forking, sequential forking cases
Summarizes: no clear answers at moment, may need improved signalling between UA and proxy,
Dean: suggests manyfolks resources procedures are incompatible with forking.
b. Jonathan ----------------------------------------- Problems with existing approach: no caller control over process. People associate 183 w/early media Requires 100Rel (PRACK)
Desiderata: -- nice to be consistent with existing process: 2-phase SDP exchange
Whole problem that early media being forced on caller, not offered to caller. Proposal: caller must offer early media, callee must answer offer. Based on principle, looks at which messages can be used for offer-answer exchange. Issues with all of the possibilities. First proposal least evil -- overlapping INVITEs, but no problem technically because of use of PRACKs.
Dave Oran: notes early termination of original INVITE -- could mess up billing. Jonathan: same principle as 401. Paul Sijben: objects to complexity of stopping call, starting it up again. Other speaker: complexity increases probability that call is lost due to network glitches. Dave O.: likes solution because it doesn't force double-booking of resources -- allows reallocation from one stream to the other. 490 provides resynchronization point.
Rohan: reasonable, but high probability people implement wrong -- race condition between second INVITE and first 200 OK. Hence favours fourth proposal.
Jonathan: already implemented for current methods -- keep old bugs rather than creating new ones with new method. Bill M.: first half OK. But .. what happens with fork? Answer: need Record-Route on 183. Second INVITE uses Route But real issue that proxy won't propagate 490 back. Jonathan thinks works out like other similar issues, but details need to be checked out.
5. NAT (Jonathan) ================
Will create separate draft on how to get SIP out through a NAT. Basic idea for UDP: new Via parameter: received port (rport) Issue: short timeout on NAT bonding for UDP -- requires resending INVITEs to refresh even when provisional responses received.
Dave O. concern with extension to Via header syntax. Jonathan: chosen method minimizes damage.
For registration: new Translate header to tell registrar this needs special handling. Rohan proposed alternative approach to avoid special handling, based on examination of source addr -- Jonathan liked, consistent with rest of draft.
Will have off-line discussion to iron out. Presented other implications of Translate header, including implementation hint for case of symmetric NATs.
Problem: intra calls. Jonathan: if high intra calling, should have proxy behind the NAT. If you don't, technique still works though it results in inefficient routing of signalling.
Michael T.: implies acceptance of single point of failure. Question: does this work for multiple NATs? Jonathan: basic condition that proxy sit in public network.
NAT detection protocol -- works whether MIDCOM there or not -- needed to take care of RTP Rohan proposed modification to increase robustness -- will discuss further Discussion on reflectors. Dave O. points out that routing problem: choice of reflector to route to -- is a really big problem.
Jonathan key point: ensure separation of media and signalling paths.
Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)
updated 13 Dec 2001 13:23 -0600