Final Minutes, SIP Working Group, IETF 50 Recorded by: Sessions One and Two: Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 taylor@nortelnetworks.com Session Three: Don Stanwyck, don@stanwyck.com Edited by: Dean Willis Note that there were two additional "BOF" meetings for SIP at IETF50 -- one on open issues, one on emergency services. ------------------------------------------------------------------------ Session One --------------------------------------------------------------------- The SIP WG met for its first session on Monday afternoon, under the chairmanship of Dean Willis , Brian Rosen , and Joerg Ott . Topic 1: Agenda Bashing ================== Dean Willis introduced the meeting and session agendas. In response to strong representations from the Area Directors, the meeting will feature larger segments in contrast to the brief discussions of earlier meetings. 2. Status of WG, led by Dean Willis (charts) ============================== Currently tracking about 70 drafts. Reached saturation point. The Chairs are trying to get control of the workload. 2.1) Proposal For Reorganization -------------------------------- Proposal: split into SIP and SIPPING work groups. Split in drafts would be about 24:40. Remaining drafts would be "out of scope". Distinguish SIP from uses of SIP. Actions: immediate split of mailing lists. Separate WG meetings next time around. Continue with same chairs until stable. Discussion: Henning Schulzrinne noted a potential problem with messages posted to wrong list: it will mean extra traffic getting the message redirected. Allison Mankin observed that if the lists become moderated to prevent message rerouting, they must have a published policy which says all that messages will be posted (except possibly spam). The Chair could have a sorting policy which assigns messages to list. IETF mailing list interactions will create complications. Brian Rosen has enforced SIP/implementor's list separation through direct notes to offenders. Jonathan Rosenberg remarked that any sorting policy won't reduce total volume, just ease processing. It was noted that some offenders of the current separation policy are familiar names in SIP work. Last Call procedures will encourage division by referring draft to appropriate list. Brian Rosen asked for comments on base idea of splitting groups. None were offered. Dean explained the new web tracking of the workload. It can be found on the SIP WG supplemental home page. Last Call: Chairs will push harder for comments to move drafts forward in time to meet milestones. 2.2.) Draft Charters For SIP and SIPPING --------------------------------------------- The draft charters for SIP and SIPPING are shown on SIP WG supplemental home page. Key charter items for SIP: - 2543bis - call control ... Flemming Andreassen noted that there are open issues regarding the privacy draft. Key charter items for SIPPING - SIPT - hearing impaired - ... SIPPING won't normally process a Standards Track change/extension to SIP. The use of extensions etc. would be described in SIPPING. Rohan Mahy remarked that adding codepoints doesn't need to go to SIP. Area Director decree: all features which may be "required" MUST be documented as standards-track items in SIP WG. SIPPING would define requirements. Jonathan noted an open issue on ambiguity regarding Contact parameter registration. Allison agreed this could be a SIPPING work item. 2.3.) Open Issues ------------------- IN interworking. Area Director agreement that a design team (SIN) review related drafts and identify issues which would prevent IN from interworking with the IN. There was insufficient support to make this an IETF work item (SIPPING charter item) at this point. Firewall passage: MIDCOM owns control Jonathan Rosenberg led a brief discussion on where call control fits. The basic principle is that "how to" is in SIPPING, extensions like REFER go into SIP. Dave Oran suggested that in effect we would double number of drafts we have now. In response, H.323 interworking was cited as a current counter-example -- no extensions are involved, so the drafts will all be targeted to SIPPING. Generally: there will be a number of corner cases. Sorting them out will require exercise of chair judgement, fed by arguments from authors. We could see a flow where the initial work is done in SIPPING, moves to SIP, and finally back to SIPPING to define usage of the resulting protocol. Security: generally a core SIP item to ensure that it is fully integrated with the protocol. Michael Thomas suggested giving it to SIPPING first because many of the issues are implementation-related. Allison Mankin pointed out that every SIPPING draft should discuss security issues. A speaker referred to the work in 3GPP/3GPP2 on SIP usage to talk to application servers: is this part of the IN mess? Henning Schulzrinne responded that this work is not necessarily part of IN. The speaker was concerned that the work as currently directed represented at the least an issue of misunderstanding of Internet architecture. The Chairs noted that one shouldn't confuse IN with 3GPP. Topic 3: Bis Issues, led by Jonathan Rosenberg (charts) ====================================== Jonathan noted that the volume of mail on the list is now such that it is no longer feasible for issues to be tracked by the leadership of the WG. He urged WG participants to take responsibility for tracking issues they raised until final resolution. 3.1) Issue: SDP in response: subset of SDP in INVITE? -------------------------------------------------------- RFC 2543 is inconsistent between the text and the examples. Requiring that the responder send back a subset of the codecs indicated by the initiator prevents the responder from indicating sendonly capabilities. It is suggested as an alternative that the text indicate that each end indicates what it can receive. Michael Thomas noted that SDP is not adapted to negotiation. UAs should use re-INVITES as required for this purpose. General agreement: the text should say that each end indicates its own receive capabilities. 3.2) Issue: Cseq Incrementing ------------------------------- The text says that sequence numbers should be "contiguous". Incrementing by 1 is useful for ordering. Robert Sparks noted that the receiving end cannot be guaranteed to see increment by 1 because of 407 sent back from an intermediate node on a re-INVITE. Rohan Mahy suggested that we try to capture the motivation for any agreed solution in the meeting minutes, so we don't have to hold the discussion again. Resolution: the UAC should still increment by 1. The receiver should do a sanity check on gaps and reset if it finds too large a gap. 3.3.) Issue: TCP Connection Handling -------------------------------------- (1) Proposal: closing of TCP connections does not affect SIP state. Assuming otherwise results in problems (per slide). The proposal raises potential backward compatibility problems. Jonathan asked the implementors in the crowd whether tyhese were real. There was positive support for the proposal. This will be confirmed on the list. (2) Need text on using persistent connections with TCP. The proposed text was shown on a chart. Matt Holdrege asked if these proposals would be carried over to SCTP. Jonathan Rosenberg cited lack of SCTP expert involvement and of understanding of how SCTP applies to SIP (why it would be needed). Allison Mankin noted that SCTP application discussion has just started in the Transport Area WG. There was a general view that this isn't a core specification item as phrased -- more of a BCP. Jonathan will think of words capturing the intent at the standards level. 3.4.) Issue: Response Failover ------------------------------- We would like calls to survive mid-transaction proxy failures. Usage of the "received" parameter prevents SRV-based reroute. Proposal: try the address given in the "received" parameter first. Upon indication of failure, use domain lookup on the Via header URI. Problems: this only works on stateful proxies. There are complications if the crashed proxy forks. Rohan Mahy suggested that the text prohibit ("SHOULD") a forking proxy from inserting a URI in its Via header which points to proxies which cannot handle forked requests. 3.5.) Issue: Tags ------------------ Agreed at last meeting: From tags should be mandatory. The specification says a tag should be unique within a UA instance. There is value in making tags unique per call leg. (Helpful with billing.) On this last point, Bill Marshall noted that a rogue UA could reuse tag values to confuse billing system. Jonathan had a different context in mind. Jonathan's proposal: make tags unique per call. A tag MAY contain a portion to associate it with the creating UA instance. Billing or whatever would actually have to gather tags off 200 OK -- INVITE only has the From tag. Henning Schulzrinne suggested we not specify implementation too closely, so that in particular, application to billing is a possibility rather than a recommendation. Rohan Mahy suggested that the proposal solves a non-problem for well-behaved implementations, and by definition the others may not do the right thing. It was also noted that this use of tags needs at least one trusted side. Jonathan Lennox referred to the discussion of the use of tags to distinguish the call-leg, as proposed in the Replaces draft. These discussions support the per-call uniqueness requirement. Jonathan proposed that we add text to indicate the implications of different implementations of tags. 4. SIP Events, led by Adam Roach (charts) ================================================== References draft-roach-sip-subscribe-notify-03.txt A new version of the draft is due. Current issues: 4.1.) State agent -- generalization of presence agent. 4.2.) Subscriptions can be initiated by other than SUBSCRIBE -- 481 must remove all subscriptions. 4.3.) PINT compatibility Lawrence Conroy noted the need for text to resolve the inconsistency between the PINT work and the way SUBS/NOT has evolved. Adam assured him that the necessary text is present (assume lack of event header implies PINT). 4.4.) Throttling needs to be done. 4.5.) Instant notification should be sent upon subscription, even though state is not actually resolved. To do this, the suggestion is to send the notification with neutral information. Jonathan Rosenberg and Henning Schulzrinne pointed out that the required action may depend on the package -- a designer issue, not a blanket requirement. Package guidelines should require designers to talk about how this situation is handled. Jonathan has other guideline items which he will provide to Adam. 4.6.) Authorization of subscriptions. Jonathan Rosenberg suggested authorization procedures also should be defined on a package by package basis. The question was raised, whether a QAUTH generalized mechanism is required. Rohan Mahy suggested that this is a special case of feature authorization. Ian Rytina argued that QAUTH has a place, but not in presence. The issue will be further discussed in SIMPLE/IMPP. In general, this is an example of a SIPPING discussion item, with outcome to be acted on by SIP. 4.7.) SUBSCRIBE response codes. 202 non-committal -- have to wait for Notify to give final result. Are 403 or 603 allowable? Does 200 mean subscription is definitively approved? Jonathan suggests that this should be part of the package definition 4.8.) Denial of service concerns: UASs should keep no state for unauthenticated SUBSCRIBE messages, to protect themselves against denial of service attacks.. Is it reasonable to allow each userid/password combination have only one pending SUBSCRIBE at each node? Dean Willis pointed out that in the failure recovery case, restart would be slow. More discussion needed. 4.9) Forking Lots of discussion at interim meeting, no resolution. The UAC gets multiple NOTIFYs back although only one 20x response was passed by the forking proxy, with Record-Route ambiguity as a result. It took some discussion for Adam to demonstrate the problem. Proposed: two solutions, one of which SHOULD be used by any subscriber. [Sorry I don't have them, hope they are shown on Adam's charts -- PTT] The event package should specify the preferred response. Rohan Mahy noted that there is a general issue with proxies forking methods they don't understand. Jonathan Rosenberg was concerned that this violates the basic SIP working assumption: that the final result of INVITE is a relationship between two parties at most. As a result, may be more general problems buried here which mean a lot of work. The suggestion is that this is an instance of a general non-INVITE forking problem. The general fix is to strengthen proxy "SHOULD" record-route on non-INVITE methods to "MUST". Session Two ---------------------------------------------------- The proposed agenda was accepted with insertion of a resumed exposition of the revised Last Call process. Dean Willis(?) explained the 1a, 2a etc notations on the web display of WG work items by indicating how they correspond to stages of processing defined elsewhere on the page. Topic 1. REFER Issues and Call Control (Robert Sparks) (charts) draft-ietf-sip-cc-transfer-04.txt draft-biggs-sip-replaces-00.txt ====================================================== Robert began with a review of recent changes to the REFER method (draft-ietf-sip-cc-transfer-04.txt). The major one was that NOTIFYs generated in response to REFER will use the Event: refer package. Road map: Model document in progress (Rohan Mahy) Splitting current draft -- extension vs. usage. Need Join/Replace for Transfer. Robert Sparks ran through motivation for Replaces: header Issues brought up: Existing call-leg identifier: the draft proposal to use tags only and not the full From: and To: headers had led to a lot of private discussion. No new points were brought up at the meeting. Tom Taylor asked for opinions on Replaces behaviour if the existing call-leg is not already fully set up. A number of people responded. - Jonathan Rosenberg was uncomfortable with the idea -- tags may be lacking. - Dave Oran thought that unwinding the state machine might be tricky. - Rohan Mahy was of the view that processing would have to wait until states of the new and old call synchronized. - Dave Oran questioned what would happen if original call forked and was ringing simultaneously at two points. Rohan Mahy argued that a referred INVITE goes through same process as original and therefore could follow the fork. Henning Schulzrinne responded that two separate processes could see separate call dispositions. - Christian Huitema viewed the suggestion as nonsensical. Nevertheless, Tom Taylor pointed out, the Replaces draft would have to define UA behaviour under such circumstances, even if this behaviour were to ignore the header. Robert Sparks continued with a walk-through for attended call transfer. Henning Schulzrinne noted that the repeated use of Replaces in a conferencing situation could lead to untraceable results. As a separate issue, he preferred Refer BYE rather than triggered BYE (as the draft has it now) -- have to be very careful not to mess up operation of other features. Speaking to that issue, Jonathan Rosenberg suggested that the entity that has resource constraints is the one which should manage the resource constraints. Robert Sparks had the view that the problem is user experience more than management of the pipe into the phone. Jonathan said the protocol should make the semantics explicit: Join + BYE. Rohan Mahy was concerned that Join implies need for mixing. He wanted to see clean separation of semantics between mixing and replacement. Robert(?) clarified the semantics of Replaces: resources from the old call are reallocated to the new one and old call is terminated. He will provide call flows. Rohan Mahy(?) made a final remark: Join without mixing makes no sense. We MUST resolve this stuff this week -- it is a major bottleneck on feature development. Topic 2: Overlap Signalling Handling, led by Gonzalo Camarillo (charts) ========================================================================= The authors of the SIP-T draft are splitting drafts so overlap signalling handling will be a separate topic. Three approaches: - en bloc - multiple INVITEs - INFO. Tom Taylor warned that which policy is used where is a matter of local policy, not standardization -- real-life implementations will have to support all three. Gonzalo continued with an analysis of the pros and cons of the three policies. He judged that both forced en bloc conversion and INFO messages (as the only means of carrying updated signalling) would be untenable. This leaves multiple INVITEs, where each INVITE carries complete state. The presented chart showed overlapping calls, a potential problem. An earlier INVITE could succeed because the partial called number is valid. Dave Oran suggested that the UAC should wait for a 484 before sending its next INVITE. Jonathan Rosenberg noted that the succession of INVITEs actually displayed Replaces: semantics. He would have to think through the consequences if Replaces were used. Christian Huitema noted that in legacy usage the PBX can hold on to a call while information accumulates. Tom Taylor pointed out that if the call terminates on an egress gateway, it has moved beyond reach of any but mid-call services in the SIP network. We need contingency plan if more digits arrive. Jonathan Rosenberg agreed that there is a problem if the call goes to egress gateway with too few digits. Gonzalo Camarillo noted a general problem: successive INVITEs may not follow the same path. The result of successive INVITEs could be extra IAMs rather than SAMs propagated onwards into the PSTN. Further discussion curtailed for lack of time. Topic 3: SIP-H.323 Interworking Requirements, led by Radhika Roy (charts) ==================================================== Radhika Roy presented status and recent changes for two documents. Review of the requirements document draft-agrawal-sip-h323-interworking-reqs-02.txt leading to Informational RFC status has been requested in various WGs in lieu of WG Last Call. The latest issue of the interworking specification is draft-agrawal-sip-h323-interworking-00.txt. Topic 4: Privacy, led by Flemming Andreasen =============================== References draft-dcsgroup-sip-privacy-02.txt Status: no real participation in the WG. New call for comments on list. Got comments from Mark Watson -- generalize components of the proposed Remote-Party-ID header. The comments were resolved after substantial discussion. The discussants gave up on the proposed inclusion of location information. Flemming showed the proposed requirements and their proposed resolution Dave Oran requested consensus that the different types within the updated proposal be IANA registered. Agreed. Comments: Jonathan Rosenberg noted that this is a Proxy-Requires extension and thus breaks interoperability. There may be ways to deal with it (e.g. sequential forwarding of the message until a path is found which works). Jon Peterson asked if it were the general view that this should be THE SIP privacy mechanism. Henning Schulzrinne agreed with Jonathan that the feature can operate, but forking gets messy. The IESG will insist on a full description of how a call will fall back to baseline operation if the extension fails. Jonathan confirmed that observation. Allison Mankin noted that work in progress may provide a method to give location information which is privacy oriented. Dean Willis followed up on Jon Peterson's question, posing it again to the meeting. Jon amplified: do we want to rely on the presence of trusted network intermediaries for SIP privacy? Dean Willis suggested that we may need more development of requirements before we can answer that question. Jonathan Rosenberg noted the need for the network to pierce veils of anonymity e.g. for malicious call trace. However, this is much tougher for SIP than for the PSTN. Dave Oran stated that the question was too broad: we can't commit to this for all SIP for all time, but real networks do have call trace requirements. Radhika Roy noted that the requirement to interwork with the PSTN adds a dimension to the problem. Addressing the content of the draft, Henning Schulzrinne observed that it is very dangerous to rely on a network entity to clean up. This issue has to be fully addressed in the draft. Jonathan Rosenberg suggested that current work focus on the requirements of malicious call trace -- e.g. when it has to be possible, in-call or later. Dean Willis raised a process issue: can we consider regulatory requirements? Allison Mankin responded that regulatory requirements are informational, feeding into IETF requirements for privacy and security. We would hope that the latter are more stringent. Note also RFC 2804. (Comments from audience to effect that the IETF shows more willingness to support malicious call trace than wiretap.) Allison suggested that the WG put together a privacy requirements draft. She observed that the current privacy draft looks very good. The suggestion was made that this document should retain its present scope, while the requirements document could have expanded scope. Michael Thomas noted a potential need for media anonymization. The question is whether this is good enough for what it is trying to do. Dave Oran responded that anonymization is solved. However, this work is driven by two requirements -- the need for an identity besides that supplied by user for processing the call, plus anonymity. Brian Rosen asked what the next move should be. He suggested the document should be split into requirements and protocol parts, and asked if there were any objection to this. He called for a hum of opposition to progressing this document to standards track. A clarification: this would be a mechanism, but there could be others. Jonathan Rosenberg wondered if Experimental be acceptable. Allison Mankin replied that Experimental is probably not appropriate. The WG should take time to get it right if necessary. The question was put: is there opposition to moving forward according to plan (July LC)? No opposition was shown. Topic 5: 3GPP Proposals, led by Keith Drage (charts) ==================================================== Keith provided URLs pointing to current documents. (These are already on the supplementary WG web site.) He walked through a signaling path chart showing how many operators could potentially be involved in a call (A's visited network, A's home network, B's home network, B's visited network). Keith presented the 3GPP functional architecture. Some questions were raised about the BCGF. It was explained as a routing function which knows where gateways are. Jonathan Rosenberg expressed satisfaction with the match to the SIP architecture. Keith provided the 3GPP approval schedule, noting its dependency on a series of drafts: 2543bis, manyfolks resource, 100rel, privacy, call-auth, subscribe-notify [and perhaps others]. Michael Thomas expressed concern regarding the applicability of call-auth. For path requirements, Keith suggested a need for a new header for hop-by-hop registration (3 registrars). Jonathan Rosenberg pointed out that this can be done with the current protocol. Jonathan Lennox asked a question to clarify the route manipulation involved. Several issues need settlement. One is Via, Route, and Record-Route hiding as in draft-byerly-sip-hide-route-00.txt. Another is notification of the UA in a proxy-initiated deregistration. Jonathan Rosenberg suggested using the SIP presence draft as a potential solution. A member of the audience indicated that this was how they were implementing the process. Topic 6: Further Discussion Of List Issues, led by Jonathan Rosenberg =============================================== 6.1) Network-initiated deregistration: Solution: use presence -- is there a consensus? Dave Oran observed that the deregistration notice could trigger something like notification of police (in the event of cell phone theft). Henning Schulzrinne asked if this is really a subject for standardization, and expressed his opinion that it is not. 6.2) 409 and Multiple Contacts: Can the current prohibition on change of action values be removed? Jonathan was not sure that the resulting behaviour would be well defined. Robert Sparks suggested that the behaviour can be reasoned out. Jonathan was not convinced. Robert provided an example of a potential application prevented by the current text. A lengthy discussion ensued. There were various proposed interpretations, but none was accepted as definitive. There are possible ways to resolve the issue, but it has to go to the list. 6.3) Record Routing: Need more comments on the new text. Issue -- what about new methods? Current text says they should not be RRed. Nevertheless, Record-Route may be justified e.g. for firewall traversal. Jonathan proposed to allow RR on any method. The UA ignores RR if it arrives on a method where it is inappropriate. Adam Roach noted that the 2543bis draft says that proxies should put RR on all methods for robustness (hence including BYE). There is a bigger issue here: what does it mean to refresh RR state? Called on time. Session Three: ---------------------------------------------------- Call to organized behavior - 9:00 a.m. Topic 1: NAT Friendliness for SIP, led by Jonathan Rosenberg ========================================== Problem: · No SIP ALG in existing NATS (No commercial ALGs today) · NATS are numerous today and won't get changed out rapidly · IPv6 might cause NATs to get replaced or updated · Can't force customers to upgrade NATs just because the service provider wants to provide service over SIP (NATs are built in to many Cable modems, DSL modems, etc.) · So proposal is to make SIP "NAT friendly" Draft-ietf-nat-app-guide-04.txt suggests some rules: · Don't put IP addresses in protocols · Clients should initiate sessions SIP predates these guidelines - how to get it to follow them now? · Find ways to ignore IP addresses in SIP/SDP when possible - get information from the transport connections. · Find ways to make peer-to-peer application look like a client server application · Don't rely on DNS since many clients do not have domain names. NAT behavior for UDP is highly variable. Assumptions are that NATs let packets out (UDP and TCP). For UDP packets can get back in only from the original destination until the timer expires - typically many seconds to a minute. Reference model is 2 UAs, each with a NAT between them and the network, and two SIP proxies between them (in the network). 4 possible configurations: no NATs, a NAT at side A only, a NAT at side B only, NATs at both sides. SIP over UDP is not NAT friendly - uses port from Via header. SIP over TCP is NAT friendly - responses go back on the existing connection. Recommendation: use TCP. Proxy to UAS routing today is through registrations. Data is wrong - is private address in private network. No NAT binding for it. Solution: Use TCP for registration, use it for incoming INVITES. UAS listens on that connection. But contact header will not point to this connection. Proposal: contact cookie. Special value that says I don't know my values, please use the values from my connection and tell me what they are. Proposes use of value like @ invalid_hostname. This causes the registrar to create new value. Fixes 3 other problems with SIP: 1) multihomed hosts, registering on public and private networks. Clients can't easily figure out different values, so let server figure it out. 2) don't know my IP address. Some hosts don't know their own IP addresses. 3) SIP Java applets - applets can only listen on the connection that was initiated with the server. SIP was designed to be independent of the transport protocol. This requires you to couple them back. TCP may go down for load balancing, other reasons. May not know why, so everytime TCP goes down you must treat it like registration timer expiry. scalability question - using TCP changes scaling dynamics. registration servers already maintain state - registration state. For SIP to be deployed we need to find a way around NATs, and this seems the reasonable solution. what about periodically refreshed UDP connections instead of TCP. doesn't work with NAT-T. the issue of inverting the port numbers means that you have to have a UDP enabled NAT, but if I have a similar hack that is proposed for TCP (I don't know my port number), it might work. maybe it could work with a via cookie, but doesn't solve the problem, since I can only get them back from the same port I sent them from. will the NAT also take care of the security issue when someone is trying to get into the network? yes. Need to clarify with the security people, but I think it does. requires every TCP machine to have a big window. true, which is why it wasn't done this way to begin with. number of connections affect scaling. perhaps. check with ?? - he has data on lots of implementations - they are all over the map. agree there is a problem, but otherwise there is no solution. what about media? not there yet. Next slides. Hard part is RTP - current RTP is unidirectional. RTP is not NAT friendly 0 designed for multicast. Solution - make RTP look like a client server protocol. A indicates IP/port to receive from B, B sends to A, A sends back to B using the source/port received in media from A. Needs only one IP address - either party. Won't work for 2 NAT problem. doesn't work if microphone and speaker are on different hosts. true. Conceptually this is symmetric RTP. Connection oriented. But who originates? Need to define active and passive participants. See draft-ietf-mmusic-sdp-comedia-00.txt. All we need is new keyword. Handles two of three NAT present cases - a NAT at either end. Both sides try, use the one that succeeds. What about both behind NAT? Many solutions possible but require something between them that is an RTP translator. Both users connect to the translator. Proxies must know if their clients are behind NATs, e.g., VIA doesn't\ match source/port, and requires client to place a visten interface into VIA header. A's proxy sends SDP with active indicated - if B is behind NAT is a problem. B's proxy acts as translator, modifies SDP to point to translator. Symmetric RTP also solves Java applet problem - SOCKS even works. Reduces number of bindings in NATs (from 2 to 1 per connection). Works with firewalls. why not use RTCP to fix it? NATs don't know port pairing rules. will break RTCP and the assumption of port pair. unavoidable, must do same thing to RTCP you do to RTP. how does this with firewalls doesn't address firewalls must have holistic solution doesn't work through firewalls only when someone doesn't want it to work through firewalls. Draft does mention methods of getting through some firewalls, but they are ugly. more firewall discussion.. Proposes use of well-known ports for UDP traffic doesn't work unless you use new demux technique on top of UDP disagree. will have to think more on it. So what needs to be done? Need framework document to describe concept. Need SIP extensions for cookie. Need SDP usage for new token, conventions for symmetric RTP. not a SIP problem, really a general, protocol independent solution for H.323, DHCP, etc. Other proposal addresses these issues. philosophical issue - trying to solve issues for SIP. Do you want new protocol to solve general problem, or a solution for this. this will be required to be in every SIP client until the last NAT in the world disappears. true. requires us to decide between changing SIP as described here and abandon the way it works today, or find other solution. this doesn't have must impact except on RTP and SDP. This solves many other problems too. really do need to find a solution to this problem. another dimension is will internal addr/port always map to same external addr/port. I think translator causes extra overhead in the network not all NATs work the way commenter describes. Translator is overhead, unavoidable. considered effects on RTCP? Lip sync, etc.? don't think there is a problem - will think about it. is SIP designed to instantiate multicast sessions? of course this won't work this way - works for unicast only ,jr> true. Recorded: Consensus:, group wants to move forward with this. Topic 2: MLPP Issues, led by James Polk ============================= References: SIP Extension for Multilevel Precedence and Preemption, draft-polk-sip-mlpp-mapping-01.txt First proposed in Adelaide. Exclusive right now to US Gov't and NATO. Sets precedence and order among all voice calls to allow identification for e.g., preemption. Is parallel to SIP efforts, and should be in core SIP. do we want this to a) be part of SIP or b) a separate thing or c) not want to do it at all? Creates a new header that has same function as emergency header, existing is an advisory header, this makes it mandatory. SIP bis has text to support 5 levels of "Priority" in header. that was put in for this - and an extension document was supposed to be written about how to map that to MLPP. needed to solve problem if giving resources to urgent calls. yes congestion is not at SIP level, instead is at socket, UDP, or someplace. advantage of doing it at signaling level is you know you were preempted. preempted user today hears tone. Also working mlpp over ip draft. what about the rest of the world? nato wants it real bad what about the rest of the world? maybe want to make a generalized solution. NATO and US Gov't are rabid about this. 1. henning change 2543 bis to define priority levels to have additional precedence levels registred at IANA. 2. extension doc with MLPP mode header with statement that the values are used as MLPP demands. Other usages can define the extensions not just NATO/US. ITU-T has at least 4 documents in this area, Europe uses it in private networks. ITU-T specs cover interactions with other services, etc. can look into that as part of the extensions. if we go IANA who enforces prioritization. not part of SIP then. bad idea, need to have SIP base precedence model that can be overridden by alternative precedence models. MLPP uses 5 down to 1. continued comments on variants of solutions . take it to the list. More support for supporting the ITU-T definition of MLPP services. Topic 3: Third party call control (3PCC) , led by Frans Haerens and Jonathan Rosenberg ============================================================= 3.1.) References draft haerens-sip-3pcc-00.txt Protocol flow for single media - see slides. Proposes sending return direction SDP in a NOTIFY or INFO. Could also use re-INVITE. Need to make decision. idea of 3pcc is to use sip without extensions. More description of the slides proposal was made in the 3GPP draft - was it considered? no. initial invite has no sdp, sdp in first ack was used as sdp in B direction, response was inserted in ack that went to A. assumes sdp-held in first message true. 3GPP uses different flows and assumptions. PRACK solution previously didn't work, but with new flows might work. also has problem with infinite ping-pong due to continuous modifications. not a problem. JR proposes to work with H to synchronize proposals since both submitted ids last day before deadline. Enhancements proposed to COMET method. was contained in earlier draft - already discussing whether it is really needed. no extensions needed to COMET as result of san diego meeting and discussions on list. not needed? not needed. 3.2.) Discussion of 3pcc updates led by Jonathan Rosenberg Problem presentation - see slides. Shows ping-pong problem. List presented alternative flow - see slides. Problem - complex, requires SDP manipulation and differing codec bindings SIP Issues from that flow INVITE on hold must not generate a hold response. INVITE without SDP means "you tell me what SDP to use" Still can use old flow if destination is known to be auto-answer automata. Otherwise use new flow. Q0S conditions difficult, not well thought out yet. No way to allow users to hear ringing when they pick up (ideally first pick up should hear ringing until other party picks up) - REFER to self has been proposed. Early media issues. refer back to self to solve ringing problem has been proposed before but has problems. true what if you have two devices trying to do simultaneous 3pcc on same parties - what impact does it have on held state entities. may be a problem if one is a B2BUA. Normally endpoint can't tell the difference between 1st party origination and 3rd party origination. normal behavior is that if you send SDP-hold you get SDP-hold back. interferes with 3PCC. Need to work through services draft. Actually, after review of the call flows, not a problem. problem seen was need to have 3rd party insert transcoder when it detects incompatible endpoints basic SIP problem, not 3PCC problem. Same as INVITE without SDP to begin with. proposes reINVITE to solve problem. Issues: 1) subset vs. no subset - rfc2543 inconsistent on whether SDP in response is subset of INVITE or not. if no overlap will send 4xx instead of 2xx. otherside doesn't know whether what I send is everything I can do. To determine there is an error must assume entity sends everything it can do. Will list codes I am able to receive, even for bi-directional streams. But maybe I can send ones I can't receive, thus causing call failure. No way in SDP to indicate a codec can only be used unidirectionally. SDP now can only list codecs I can use full-duplex. problem transcends SIP, needs input from SDPng group. everything uses SDP differently. incompatible with PacketCable in this and other ways. Should support most common models. Need to sync with SDPng. What is the default interpretation? trying to define normative text need to define associations. We must first decide default - seems to now be that not sure subset is necessary? The default is you send the codecs you can send/receive, and the response is a subset of that. response does not have to be a subset of that. problem - if A can send and receive codecs 0, 1, B can send/receive 7, 8. Want to reject call of there is no overlap. But there may be asymmetric codec use that would work. How to identify both bi-directional and uni-directional codecs? there are two cases - symmetrical connections and asymmetrical connections. For symmetrical connections current methods work. Can be solved by adding association between media lines in an SDP. won't be acceptable since that violates base SDP spec. need to be able to give B enough notion of what A can do, both uni- and bi-directionally. presence of multiple codecs in SDP means can do them all simultaneously. not everyone comfortable with this - want way to say can do codec 1 or 2, pick one, can't do both at same time. trying to figure out what exactly the problem is - proposal to split every stream into 2 uni-directional streams. Some feel that is not viable because "95%" of streams are between entities that only support bi-directional codecs. do we have agreement that the codecs in the INVITE sdp for send/receive streams are codecs I agree I can both send and receive. then the response is the subset of those that party B can both send and receive yes, the response should contain at least the subset (null?), but may have others that B can send/receive. Still not determined if the response set must intersect the initial set. Discussion deferred to the list. Summary of BOF: Record Route - proxy can record route on any method. If UA has no route record for a call it is set by the first received one. If it exists it is not updated by subsequent ones. Transfer out of consultation: issues remain - will go to the list.