Notes, SIP/SIPPING Interim, May 25, 20004 recorded by Dean Willis Additional Notes, Morning Session -- Bill Marshall KPML Issues and Updates Martin Dolly Slides Presented Changes since last version reviewed in slides. More changes are needed to address extant comments. Issue: 2833 Suppression and H.323 interworking at gateway elements: There was no conclusion during the discussion. A small design group was assigned to discuss and report back. Issue: Quarantine of Digits Prior to Subscription Activiation: Several thorny situations arise when multiple KPML subscribers exist simultaneously or have overlapping setup. If one application is controlling prompt play out and another is listening to DTMF without synchronization between teh applications, it is possible to get into a state where one application's subscription is "behind" on its digit reception. Much confusion followed. A small design group was assigned to discuss the problem and report back. Issue: Proposed to eliminate enterkey and OR expression, add flash-hook and backspace inputs. We seem to have consensus on deleting enterkey. Polled room on need for OR operator -- no speakers claimned a need for it. Author directed to raise specific question of OR expression on-list. Room polled on backspace, with no use cases brought out. Discussion extended into extensibility of KPML with respect to other markups for specified devices, ISDN feature-key signaling, etc. The general concern is that KPML is NOT intended to be "MGCP over SIP". Proposed that KPML be formally limited to keys available on analog GSTN. Room polled: none opposed. Suggested that people ARE going to extend it, and we should give some direction on that. Specifically, we wish future work to be presentation-specific ratehr than presentation-free. Suggested that the KPML document specifically reference the framework document for discussion of extensibility. Issue: Fixed set of timers versus timer-per-expression. Proposed that we retain a fixed set of timers. This led to a discussion that seems to indicate that we need better examples in the draft, specifically relating to input termination when a pattern is specifically matched and no other matches are possible given the current patterns and input state. Issue: MIME types, schemas, and namespaces used with KPML may be somewhat "intertwingled". Suggested that we clarify starting from the position "KPML is an event package -- it needs a filter in the SUBSCRIBE, and NOTIFYs that contain appropriate events. The fundamental event being reported is different from the filter definition or the keymaps used to select it. Alternate suggestion made that the distinction be made based using MIME parameters. The fundamental question appears to be whether we would ever implement one without the other. There seems to be a slight consensus that we will continue to maintain seperate MIME types at this time, but will also continue to consider the problem. Issue: Relationship to App-Interaction. We appear to have a normative relationship to app-interaction. The author of app-interaction feels that it can be advanced concurrently, so we conclude to maintain the normative dependency at this time. Question on scope wrt remote-end-monitoring: The text of Figure 3 refers to a "media proxy". This is apparently confusing. It was proposed that the application should be independent of the physical topology of the endpoint. Conclusion: More work is needed to clarify this in the app-interaction framework. Figure 3 should be removed from the draft. Issue: Sustained Rate. Proposed in Section 3.10 that we add a Sustain-Rate (as required for event packages), limited at no more than 100 notifies per minute. Consensus to accept this proposal recorded. Question: Did we just add hook-flash back into the document? No. R-button? If somebody comes up with a use case or declares a need, we can add it. Question: What is the impact of unreliable digit sequencing and overlaping notify? The draft needs to have some discussion of this, and probably needs to include KPML sequence numbers. GRUU Jonathan Rosenberg Slides Presented Note: KPML depends on GRUU Changes agreed at IETF 59 reviewed. Issue: Format of Instance ID. Will reference UUID informatively. The uniqueness requirement for instance ID is "unique within an AoR". Note that we may need to add text to the UUID reference reducing the requirement for global uniqueness and its implication on the selection of appropriate UUID generation techniques. Note: Author requested to send note to MID list on UUID topic. Issue: temporal scope. This no longer works -- the scope is now tied to instance registration, and when there are no contacts registered, one gets a 404. What are the implications of this return code on clients? Do they discard the gruu, try again, or what? Proposed taht doc give guidance on return codes based on implementations knowledge of GRUU construction and persistence in that implemantation. Issue: GRUU is not necessarily a product of registration. It can be a property of an AoR, or a configured property of a URI, or something else. It is proposed that some text clarifying this would be appropriate. No objections made, although several clarifications were suggested in the ensuing discussion. Issue: UA physically divided into UI and signaling bits. Since only one GRUU is indicated in the siganling, making this work requires a back channel between the components. Proposed that we ignore this case. No objections noted. Issue: Meaning of REGISTER with Contact:* Expires:0. Proposed that we stay with current meaning -- delete all contacts. No objections. Issue: GRUU with no instance ID. Conclusion: Change text to not mandate a URN, but a URI, but suggest that URN can be used if persistent temporal scope is required by the application. Issue: Provide GRUU to Server (client proposal of GRUU during registration). Proposed that this is left out of scope of the current document. No objections recorded. Issue: BIG GRUUs. Suggested algorithm generates >100 byte GRUUs. Is this a problem? Proposed that since this is just a SUGGESTED alogorithm, that's OK. Author will also provide some additional suggested algorithms, including one using a hash of AOR and instance ID (optionally with a private key). Session Independent Policy Volker Hilt Slides Presented Changes since last meeting reviewed. Poll: Are we ready to adopt this as a working group draft and baseline text towards the existing charter goal? No opposition noted. Session Specific Policies Volker Hilt Slides presented Issue: Piggyback versus Seperate Channel transference of policy. Session Policy Rohan Mahy Slides Presented Slides include tutorial background. Question: Should it be possible for a SIP proxy server to apply policy based on the answer to a SIP O/A sequence? This seems to be a requirement. Discussion of this requirement proceeded Issue: Response authentication. There appear to be issues in 3261 that allow for insertion of spoofed responses, even if TLS is used. Several possibilities exist for correcting this: 1) Adjusting 3261 to require proxies to correlate TLS identities between requests and responses, 2) using S/MIME to integrity protect and authenticate responses. Cullen and Jonathan will work on addressing this in a 3261 addendum. Not forwarding stale resposnes fits in here somewhere too. Discussion: A session policy use-case draft would be helpful. Very helpful. We should be able to extract use cases from every place that 3GPP has found it necessary to document SDP rewriting. Implication: Network operators that want to be very restrictive in policy have to be willing to accept the overhead of hoop jumping. Exploders Gonzalo Camarillo Slides presented Primary task: Address amplification issues. Primary approach: Opt-in with real-time removal. Discussion of hows, why's and usage scenario follows. The specific threat model of interest is a strongly exploder deployed by a large-scale operator Point: ad-hoc lists still make sense. The ad-hoc list just has to contain URIs that have already been authorized for inclusion. This means that authorization should occur as early as possible -- for example, as soon as a URI is inderted into a user's friend list. Point: We need to figure out preventions for the voice-hammer DOS attack, too. Point: Long ago and far away we had sri-nic mailing lists. It was noted then that the current problem with lists, exploders, etc. is entirely due to the fact that email was built as any-to-any, then one-to-one, then one-to-many, and worked well enough for many-to-many. This opt-in model as proposed works if we accept the the side effect of changing SIP from an any-to-any mesh to a connected mesh of consenting parties. If we do NOT accept this change, then the changes we are making here are not going to help a lot. Question: Will this apply to conference servers and the like? Yes. is it possible to do this with some other mechanism like CPCP? Yes, probably. Suggestion: We are bridging between domain boundaries. Maybe each domain should just worry about protecting itself rather than protecting other domains. Several suggestions made that this sort of approach is far too heavy, and instead we should rely on operational controls and limits in exploders to keep us safe. After all, operators can be expected to configure their servcies in a reasonable manner. Issue: Communicating the List, URI-Parameter vs Header. This is complicated -- we use the URI both as a locator, and a name. Arguments issued for both approaches. However, we need to work with GRUUs, and the grid parameter is "special cased" because of the transparency requirement. Counterarg: These parameters make sense only to a specific target, whereas header parameters are likely to apply to anything. This indicates that we have a more general problem that needs resolution. Another alternative is a body addressed to the exploder. Proposal: Carry the content-id in the grid parameter. Clearly, URI transforming proxies are going to break parameters passed in URIs. This is not a conventional setting for off-the-shelf proxies. Proposed that we need to carry this particular bit of information is more accurately an aspect of MIME than of SIP, and consequently should be carried and indicated entirely at the MIME level. This would seem to make it immune to retargeting and header mangling. Connected Party and Identity Jon Peterson Slides Presented Issue: Header vs Body for Identity. The debate centers on the specification for header and body treatement vs the treatment effected by deployed systems. DEFER! Changes since last draft reviewed. Discussion: Are we worried that we can't trust a proxy to route a request for us? In a pure redirect model, we don't have this problem. Given this, one can argue that the connected party problem is a subset of the request history problem, and that derivation of the connected party is exactly the request history problem. The draft now recommends a redirect when retargeting a request from one AoR to another. Question: How is this determination of domain-AoR referral established? Basically,, we re-use connection reuse, and only proxy when the outgoing connecton toward a contact is the same as the connection from which that contact registered. Note that this appears to break the general use of parallel forking. Comment: The proposed canonicalization approach is going to be very difficult to implement correctly. We allegedyly decided about four years ago that adding headers with hashing, etc. was problematic and should be avoided. Comment: The current spec seems to allow proxies receving a 302 response to recurse. We need to check 3261 for clarity on this. Comment: The To: header in a request following a 302 may be the original To:. Consequently, the signed value of target may mismatch in the derived request. Question: What should a UAC do when a response has a mismatched identity? Probably display the response, but indicate the problem to the user -- they are not connected to the party they expected. Certificates and S/MIME Cullen Jennings Slides More or Less Presented Issue: One must be able to trust the domain principals of one's AoR. Dialog Package Rohan Mahy Slides Presented Changes slince last presnted. Issue: Hold. Does this need a callee-caps feature tag for interactivity? How does this relate to the automata tag? Extensive debate followed. Proposal: a=inactive or sendonly or some other SDP parameter that indicates whether the media is or is not being rendered to a user. Does this mean it's ok to eject a node with this behavior from a conference? How does this correlate to the "unable to send a BYE" property?