SIPPING Notes IETF 64 recorded by Dean Willis Topic: Agenda and Status Chairs Slides Presented TISPAN and P2P Ad-Hocs announced Hihsam Khartabil and Dean Willis volunteered to record notes on the meeting. Noted that the wireless network in the room is not working and we therefore do not have a scribe for the Jabber chat room. Status: Three drafts (qsig2sip, config-framework, torture-tests) have been submitted to IESG review. A small amount of text relating to certificates will need to be removed from the config-framework document and moved to a separate docs by Dan and Cullen and Rohan. The new text will then be reviewed by the WG. Several drafts have completed working group last call. TASK: Clarify where dialog usage task ended up (SIP or SIPPING). Topic: Config Framework Led by Dan Petrie Slides presented Issue: Merging Question: Are we suggesting that we remove discussion of merging from the drafts? It seems that some of the things we did in the drafts are so complicated that they are wrong. if this is so simple, why do we need all the stuff that's in the dataset draft? Noted that a proposal will follow later in the discussion. Discussion followed. Noted that the current data model doesn't allow things like merging UDP data port constraints. It is easier to construct the data model such that merging is easy (delete some policy attributes perhaps) than it is to provide a general merging-engine in all nodes. Issue: Data format, XML vs ABNF Discussion on "How much validation is really required in the client?" and "What data format to use". Conclusion: Stick with XML schema as used in SIMPLE. We no not appear to have a requirement for strong XML validation in the client. Issue: Route Set vs. Single Hop. Argued that we have requirements for defining a "route vector" for each profile, or at least for the whole UA, and that in no case does a "single route hop" satisfy the framework requirements. Debate was inconclusive. Issue: Which data sets should be working group items. Proposal: If we have a SIP/SIPPING document that describes a data element as configurable, then we should have a config data set for configuring that data element. Topic: Session Policy Framework and Data Set Formats Led by: Volker Hilt Slides presented TASK: Add a milestone date for the session policy framework to the charter. Issue: Which format for policy decisions in session-specific policy? Question: Does SDP work for use case where use of video with a specific domain is not allowed? Response: That use case would seem to be appropriate for session independent, rather than dependent, policy. Question: Is it okay to set ANYTHING in the SDP? Like maybe the private key for SDP? Answer: yes. Conclusion: We seem to have a consensus for SDP format. Topic: Consent Framework Led by: Gonzalo Camarillo Slides presented Proposed that we remove "operations" part. Question: Does this impact the ability to refuse messages wile accepting phone calls, etc. Or is that bounded by the consent-request itself? Noted that the documents will be revised shortly based on list comments. Discussion: Do we have "exception" mechanism, like "all but Bob"? The problem is that these policies are installed on servers that have little interest in enforcing complex policy. Proposed therefore that the answer is "no" -- the only thing that you are allowed to do is authorize a specific sender, and only for URI-list services. Topic; Conference Bridge Transcoding Model Led by: Gonzalo Camarillo Slides presented Issue: Incompatibility type. Question: What if the transcoding problem weren't just codecs, but were addressing issues or something else? What about pair-wise coding mismatches? Request: There should be a very clear statement about how a transcoder decides what it is going to put in its offer. Issue: Does Consent Apply? Suggested: No. Discussion: There is another thing that the consent policy framework helps with, which is prevention of relay attacks. Further discussion deferred to list. Topic: IPv6 Transition Led by Vijay K. Gurbani Slides presented Issue: Whether or not to use TURN to obtain v4 or v6 issues. Gonzalo and Jonathan followed some discussion with IAB, and reports that there seems to have been no explicit conclusion. The topic will be further explored in BEHAVE. Issue: Torture-test materials. Discussion: Should we be doing examples of using network APIs. Suggested that we do NOT. Issue: ipv6-sip-01 draft Comment: When you have both A and AAAA records and are using UDP in a non-invite transaction, and try v6 first, and something in the middle blocks v6, then the whole thing fails. This may be referenced in the "not-futures" draft. It may also relate to lack of specificity in RFC 3263. Comment: Draft tackles two things, and its role is unclear. It is both a survey, and a discussion of some specific mechanisms in detail (the torture tests). Suggested that we remove general v6 strategy discussions If a UA is running multihomed with a colocated identity server and registrar, do we need to redo the identity server assertions when switching from v4 to v6? Discussion on futures. The WG is interested in working on this, but remains undecided as to whether to schedule this work immediately or defer it for a future schedule. Topic: SIP Unfriendly Functions in Current Communications Led by: Jani Hautakorpi Slides Presented Noted: The slides say "These functions are implemented mainly in SBCs". But we have found instances where implementers of non-SBC devices have noted this sort of behavior in non-SBC devices. Therefore the next revision of this draft should take into account that the audience is NOT just SBC implementers. Proposed: instead of documenting all the ways one could break SIP, the group should focus on documenting the requirements for features that SBCs currently provide, like topology hiding. This would then allow us to have a discussion about HOW we should go about meeting those requirements. TASK: Chairs to meet with various authors on this work and align terminology and Issues: Concrete exampled. Latest rev has some. Proposed that this is overkill.Cllen will send some discussion to the list on this topic. Question: Is this a useful document? Does it need to be made into an RFC? There seems to be agreement that the document is useful. Topic; Max-Forwards Problem in Proxies Led by: Robert Sparks Slides Presented Discussion: What can we do about controlling the number of requests versus capping max-forwards Proposed: We could re-implement explicit loop detection. Discussion indicates that this could be O(1) per proxy or O(n) across n proxies, rather than O(n^2) as per our earlier loop detection attempt. Another proposal: Cap the number of retargetings, especially across domains. Comment: Forking across domains is far more problematic than within a domain. Also, the only place that you gain value for loop detection is on the proxies that actually fork. So if proxies fork, they also need to do loop detection. Comment: There may also be spiral-explosion cases, and this might influence our design. Comment: We can also deal with this by eliminating arbitrary registration of contacts, and the text in sip-outbound is taking us that direction. Comment: If a proxy is going to do stupid stateful forwarding functions, it must be responsible for cleaning up afterwards. Issue with proposed return of error message as sipfrag in 423: Noted that this may run into UDP packet size. Comment: Most SBCs will actually prevent this attack today. Conclusion: We shall conclude the discussion of how to fix this in the SIP working group, considering this as a "bug report". Note: 3261 does have loop detection. Topic: Multi-Transcoding Led by Tae-Gyu Kang Slides presented Question: Is the goal here to correctly signal a tandem transcoding, or to provide for withdrawal of transcoders from the path? Use case: If a call is placed through a transcoder, and the transcoder cannot complete an O/A match with the next hop, then a 488 response would indicate a problem with the transcoder, not with the "far side". This may justify a new response code. What is the use case that gets us into a situation with more than one or two transcoders? The draft will need to clarify this.