Tuesday 5/25/2004

Interim meeting of SIP/SIPPING Working Groups

Notes for first half day:

Blue Sheet announcement

Note Well announcement

Lunch today, funded by Nokia, at 12:00

Agenda bashing

9:00-10:30: KPML

10:30-11:00 GRUU

11:00-12:00 SessionPolicies

12:00-13:00 – Lunch

13:00-14:30 SessionPolicies Continued

14:30-15:30 Exploders

Changes: none

KPML, Martin Dolly, AT&T

Slides summarize updates to the -03 document, and discussion since it was submitted

• Support of GRUU in section 2.3, Operations
• Added explanation of the digit buffering mechanism in 4.1.1, User Input Buffer Behavior
• Clean up “No Call Leg” Section 3.7.5
• Clarification on digit timers, 4.1.2.1
• Other editorial changes

Comments/issues with KPML document:

• Digit suppression when interworking with H.323: there is no mechanism to request suppression of digits. Proposal: to remove the capability of suppressing the 2833 packets, since you can’t properly interwork the request with H.323. Francois noted that H323 v4 was first time when in-band DTMF was supported, prior to this it was always sent out of band. Cullen: problem that anyone who can send KPML to the device could suppress the end-to-end DTMF and break lots of other features. Chair: propose that we get a proposal written on the flipchart in the hallway.
• Quarantine of digits before subscription. Proposal is to not support quarantine of digits prior to a subscription. Implication is that there is now a race condition, and early digits may be lost. Cullen: problem is security, that a subscriber could get all pin numbers, calling card info, etc, that was entered as part of completing the call. Jonathan: asking the UA to buffer digits when there may never be a request for them, seems wrong. Probably odd timing problems, too, and may lead to unbounded latency of the digits. Rohan: Loss of first digits is a big problem. Propose that quarantine be limited to 64 seconds (max time between INVITE sent and SUBSCRIBE sent); problem is that the voice announcement may not be coming from the same place that will be sending the subscribe. Security is a problem, but there are simple solutions to it. Detail of problem: Invite has arrived; application knows about session, has sent subscribe (but message was lost). Dave Oran: similar problem with SpeechSC with barge-in. Whether the buffer gets dumped at the transmitter or at the receiver is a choice, but you need explicit barrier synchronization. Suspicion that we need state communicated in the subscribe that indicates the barrier point. Jonathan: not clear how the UA can know when the barrier happens. Dave: need both to authorize, and to specify where in the event stream the barrier happens. Also there may be multiple applications running KPML, so not a simple mutual exclusion. Cullen: knew when we started that it would be simple and not solve everything. Rohan: calling card application should be responsible for issuing a flush command that would cause all DTMF prior to this to not be given to subsequent subscriptions. Cullen: this just moves the problem around, and doesn’t solve it. Rohan: it is an important problem that needs a solution. Jonathan: convinced that this problem can be solved by careful timing of the signaling messages, and then quarantine of digits is not needed. Dave: quarantine deals with type-ahead. Jonathan: user typing before connected? Dave: yes, like a re-dial button. Jonathan: don’t 200-OK the INVITE until the SUBSCRIBE is acknowledged. Agreed: group will draw some call flows and try to resolve off-line
• Proposal to get ride of EnterKey and OR expression, add FlashHook and backspace. EnterKey (pound) following digits, and only the digits would be sent. OR expression is a simplification of patterns. Flashhook and backspace is adding syntax to accommodate these additional patterns. Jonathan: see nothing gained by the Enter Key, so remove it; use case for OR is unclear, and is an issue only if the number of patterns will become exponential. Chair: poll for application of OR: none. Chair: Martin should send email to list asking for applications of OR and a use case where its removal will be a problem. Alison: got input from Lucent that they wanted to add keys in the future, can the design accommodate this? Jonathan: scary. KPML designed for a specific keypad interface. Cullen: people will all want to extend this, and we should control how this happens. Example is a conference button in a big phone. Keith provided details of what ISDN does with the conference button. Rohan: propose that if the button doesn’t exist on the analog public switched network, then we don’t include it in KPML. Others are explicitly out of scope, and do a different kind of markup for those. No reason why those can’t be similar, but they will be different. Keep us from having an arbitrary bucket of incompatible crap. Francois: if people don’t have the ability to signal a button, they assign a key sequence to a button. They will do it, and we don’t really care. Support not looking at extensibility for now. Alison: add a pointer in KPML document to the discussion in the framework document regarding extension. Conclusion: things which appear on keypads of analog PSTN telephone are in scope, and which do not are not in scope. 0-9, *#, flash hook, ABCD. Enter Key will be removed. No use case given for backspace.
• Multiple timers versus timer per expression. Propose that we stick to one timer per expression. Example: interdigit timer that would apply to all keys in the subscription, versus a separate timer for each use. Cullen: a timer exists now that causes digits to be sent when timer fires, even if nothing matches. International numbers can’t be done now with the existing three timers; a single timer per regular expression is sufficient. Dean: two possibilities: a fixed set of timers that apply to everything. Other is to have a separate timer for expression. Conclusion: no normative changes, but need more clarifying examples of use of timers in the draft.
• Addition of GRUU, remove references to dialog reuse. No discussion.
• MIME type for the filter in the SUBSCRIBE and reported events in NOTIFY are quite different. Suggestion that they be separate. Jonathan: suggested this, filter is in the subscribe, events in the notify; KPML is an event package. Ted: suggest that it be a single MIME type, with two parameters instead. This signals to the implementers that doing one without the other is not useful, and that both will be implemented. Conclusion: Strong consensus of “no-opinions”, chairs will make a decision. Keep them separate.
• Draft timing: KPML will move forward with App-Interactions, so normative references between them will not delay publication of KPML.
• Scope, and the use of Media Proxy in Figure 3. Conclusion: Figure 3 should be removed, as it is covered in the framework document, and the use of the term “proxy” is misleading (since it is a B2BUA and not a proxy).
• Proposal to add a Sustained Rate in 3.10, of no more than 100 notifies/minute. Conclusion: OK, but need to state that overlapping NOTIFIES will happen.

GRUU, Jonathan Rosenberg, dynamicsoft

Mostly done with spec. Lots of pending documents have normative refs to GRUU.

Pending changes from IETF-59: have been entered into the draft

Remaining issues:

• Format of Instance ID just a string now. Want something with structure to avoid conflicts across namespaces. Proposal is that Instance ID is a URN. URN value must be selected so that UA knows that no other instance with the same AOR would pick the same value. Alison: might not have the chain of reference to UUID. Ted: there are several security concerns about generating UUIDs. If using UUID URNs then need to add text saying that security concerns are not major. Alison: possibility to use the technique of UUID URNs, and import the text and just call it an instance ID. Action item: Jonathan to send email to NID list asking about namespace that would be appropriate for Instance IDs.
• GRUU properties, routes to a single UA instance, temporally scoped, and global. Temporal scope no longer makes sense, since same URI will be assigned when UA instance re-registers. Error 404 (vs 410 vs 480) doesn’t seem right. Persistent storage of GRUUs that are temporarily unavailable is real burden on registrar. Lots of arguments 404 vs 410 vs 480. Conclusion: If the registrar can identify a GRUU as one it generated (but not currently valid) then 410 or 480; if it didn’t generate the GRUU then 404.
• Administrative GRUU Creation. Proposed to document administrative assignment as a means for GRUU construction, and scrub text to make sure there is not a registration bias (particularly the informative text regarding the UAS, e.g. section 5). Cullen: problem with having to enter administratively created GRUUs in several places. Conclusion: as initially proposed.
• Separate UI/Signaling Component – the UI (with Keypad) on one host, but the signaling handled on another host. Result of list discussion was to require some kind of communication between the UI and signaling component in this case. Conclusion: confirm result from list.
• Meaning of “Contact: *” with “Expires: 0”. Means either (1) delete all registrations, or (2) delete all registrations with this instance ID. Proposal that this still means to remove all registrations. Conclusion: OK
• Proposal to allow GRUU to work without instance ID, bound only to Contact URI (the way GRUU used to work). Ted: with URNs, fundamental requirement is that the namespace maintainer will never reassign a name. Chair: propose that this be ruled out of scope. Conclusion: mandate a URI, not a URN.
• Proposal to allow a client to propose GRUU to the server. Conclusion: don’t do this.
• Issue with big GRUUs. Suggest algorithm for stateless GRUU requires AES encryption a concatenation of AOR, instance ID, salt; can result in really long GRUUs (like 129 bytes in one example). Sigcomp can do compression across multiple messages. Dean: this is a suggested algorithm only, can use a different one. Cullen: We don’t have stateless registrars, so this is less of an issue. Jon: can use just a cryptographic hash of the AOR and InstanceID. Resolution: Jonathan will work some text using a hash in the registrar as another suggested algorithm.
• Other questions and comments: none.

Session Policies, Volker Hilt, Lucent

(starting at 11:35, will adjourn for lunch at 12 and get back to this topic after lunch)

Session-Independent Policies

• XML-schema for session policy documents
• User Agent Profile Delivery Framework to deliver policies to UA
• Changes from past version on viewgraphs
• Chair: poll to make this a work item for charter: humm passed. Will become a WG item after approval by AD.

Session-specific policies, draft-hilt-sipping-consider-policy-00

• Piggyback model has some drawbacks, required both UAC and UAS to support it. Also does not support “asynchronous” policies (policy changes during a session).
• Separation of tasks: UA needs to disclose information about the current session to the proxy, and proxy needs to send policy instructions to the UA. Policies can apply to the offer and/or answer; mechanism needs to support both.
• Proposal to use a separate channel from proxy to UA; UA uses subscription to policies, and receives NOTIFYs on new and updated policies. URI for policy subscription provided to UA in a header/4xx response body, or through configuration. The way policies are transferred is same mechanism as session-independent policies.
• Disclosing the session information: two alternatives (1) piggyback model, along with the offer/answer, and (2) use a separate channel.
• Open Issues: which model? How to realize a separate channel? To be discussed after lunch break