NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Joerg Ott <jo@tzi.uni-bremen.de>
Brian Rosen <brian.rosen@marconi.com>
Dean Willis <dwillis@dynamicsoft.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Allison Mankin <mankin@east.isi.edu>
General Discussion:sip@lists.bell-labs.com
To Subscribe: sip-request@lists.bell-labs.com
In Body: subscribe
Archive: http://www.bell-labs.com/mailing-lists/sip
Note: There is another SIP email list for general information and implementations:
Discussion of existing sip: sip-implementors@cs.columbia.edu To Subscribe: majordomo@cs.columbia.edu In Body: subscribe sip-implementors Archive: http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors =======================================================================
The Session Initiation Protocol (SIP) working group is chartered to continue the development of SIP, currently specified as proposed standard RFC 2543. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main work of the group involves bringing SIP from proposed to draft standard, in addition to developing proposed extensions.
Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular:
1. Services and features are provided end to end whenever possible.
2. Extensions and new features must be general purpose, and not applicable only to a specific set of session types.
3. Simplicity is key.
4. Reuse of existing IP protocols and architectures, and integrating with other IP applications, is crucial.
SIP was first developed within the Multiparty Multimedia Session Control (MMUSIC) working group, and the SIP working group will continue to maintain active communications with MMUSIC. This is particularly important since the main MIME type carried in SIP messages, the Session Description Protocol (SDP), specified in RFC 2327, is developed by MMUSIC. The group will also maintain open dialogues with the IP telephony (iptel) working group, whose Call Processing Language (CPL) relates to many features of SIP, and the PSTN and Internet Internetworking (pint) working group, whose specification is based on SIP; and will consider input from the Distributed Call Signaling Group (DCS) for distributed telephony services.
The specific deliverables of the group are:
1. A Draft Standard version of SIP.
2. Completion of the SIP call control specification, which enables multiparty services, such as transfer and bridged sessions.
3. Completion of the SIP caller preferences specification, which enables intelligent call routing services.
4. Completion of the SIP INFO method extension, used for carrying SIP session related information.
5. Completion of the "183 response" extension, to enable early session establishment.
6. Define a MIB for SIP nodes
Other deliverables may be agreed upon as extensions are proposed.
Done |
|
INFO Method extension submitted to IESG |
Feb 00 |
|
Early session establishment extension submitted to IESG |
Mar 00 |
|
Caller preferences specification submitted to IESG |
May 00 |
|
Call control specification submitted to IESG |
Jul 00 |
|
Draft standard version of SIP submitted to IESG |
Jul 00 |
|
SIP MIB submitted to IESG |
· SIP Caller Preferences and Callee Capabilities
· Reliability of Provisional Responses in SIP
· MIME media types for ISUP and QSIG Objects
· SIP Telephony Call Flow Examples
· Management Information Base for Session Initiation Protocol
· Guidelines for Authors of SIP Extensions
· SIP: Session Initiation Protocol
· SIP: Session Initiation Protocol -- Locating SIP Servers
· SIP Extensions for supporting Distributed Call State
· SIP Extensions for Media Authorization
· Integration of Resource Management and SIP
RFC |
Status |
Title |
RFC2976 |
PS |
The SIP INFO Method |
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 <dwillis@dynamicsoft.com>, Brian Rosen <brian.rosen@marconi.com>, and Joerg Ott <jo@tzi.org>.
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 <hgs@cs.columbia.edu> noted a potential problem with messages posted to wrong list: it will mean extra traffic getting the message redirected.
Allison Mankin <mankin@isi.edu> 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 <jdrosen@dynamicsoft.com> 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 <fandreas@cisco.com> 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 <rohan@cisco.com> 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 <oran@cisco.com> 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 <mat@cisco.com> 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 <rsparks@dynamicsoft.com> 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 <matt@ipverse.com> 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 <wtm@research.att.com> 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 <adam.roach@ericsson.com> (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 <lwc@roke.co.uk> 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 <ian.rytina@ERICSSON.COM.AU> 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 <taylor@nortelnetworks.com> 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 <huitema@exchange.microsoft.com> 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
<gonzalo.camarillo@lmf.ericsson.se> (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 <rrroy@att.com> 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 <mwatson@nortelnetworks.com> -- 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 <Jon.Peterson@level3.com> 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 <drage@lucent.com> (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 <lennox@cs.columbia.edu> 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 <sip user> @ 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.
<comment > 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.
<comment > scalability question - using TCP changes scaling dynamics. <answer> 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.
<comment> what about periodically refreshed UDP connections instead of TCP.
<answer> doesn't work with NAT-T.
<comment> 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. <jr> 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.
<comment> will the NAT also take care of the security issue when someone is trying to get into the network? <jr> yes. Need to clarify with the security people, but I think it does.
<comment> requires every TCP machine to have a big window. <jr> true, which is why it wasn't done this way to begin with. <comment> number of connections affect scaling. <jr> perhaps.
<comment> check with ?? - he has data on lots of implementations - they are all over the map. <jr> agree there is a problem, but otherwise there is no solution.
<comment> what about media? <jr> 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.
<comment> doesn't work if microphone and speaker are on different hosts. <jr> 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.
<comment> why not use RTCP to fix it? <jr> NATs don't know port pairing rules.
<comment> will break RTCP and the assumption of port pair. <jr> unavoidable, must do same thing to RTCP you do to RTP.
<comment> how does this with firewalls <jr> doesn't address firewalls <comment> must have holistic solution <jr> 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.
<comment> more firewall discussion.. Proposes use of well-known ports for UDP traffic <jr> doesn't work unless you use new demux technique on top of UDP <comment> disagree.
<more discussion about configurations of firewall - disagreement between commenter and jr about utility of commenter's solution.> <jr> 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.
<comment> not a SIP problem, really a general, protocol independent solution for H.323, DHCP, etc. Other proposal addresses these issues. <jr> philosophical issue - trying to solve issues for SIP. Do you want new protocol to solve general problem, or a solution for this.
<comment> this will be required to be in every SIP client until the last NAT in the world disappears. <jr> true. <comment> requires us to decide between changing SIP as described here and abandon the way it works today, or find other solution. <jr> this doesn't have must impact except on RTP and SDP. This solves many other problems too. <comment> really do need to find a solution to this problem.
<comment> another dimension is will internal addr/port always map to same external addr/port. I think translator causes extra overhead in the network <jr> not all NATs work the way commenter describes. Translator is overhead, unavoidable.
<comment> considered effects on RTCP? Lip sync, etc.? <jr> don't think there is a problem - will think about it.
<comment> is SIP designed to instantiate multicast sessions? <jr> of course <comment> 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.
<comment> 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. <comment> that was put in for this - and an extension document was supposed to be written about how to map that to MLPP.
<comment> needed to solve problem if giving resources to urgent calls. <mp> yes <comment> congestion is not at SIP level, instead is at socket, UDP, or someplace. <brian> advantage of doing it at signaling level is you know you were preempted. <mp> preempted user today hears tone. Also working mlpp over ip draft.
<comment> what about the rest of the world? <mp> nato wants it real bad <comment> what about the rest of the world? <comment> maybe want to make a generalized solution. <mp> NATO and US Gov't are rabid about this.
<comment> 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
<comment> 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. <brian> can look into that as part of the extensions.
<comment> if we go IANA who enforces prioritization. <brian> not part of SIP then. <comment> bad idea, need to have SIP base precedence model that can be overridden by alternative precedence models. <mp> MLPP uses 5 down to 1.
<comments> 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.
<comment> idea of 3pcc is to use sip without extensions.
More description of the slides
<comment> proposal was made in the 3GPP draft - was it considered? <h> no. <comment> 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. <jr> assumes sdp-held in first message <h> true. <jr> 3GPP uses different flows and assumptions. PRACK solution previously didn't work, but with new flows might work.
<jr> also has problem with infinite ping-pong due to continuous modifications. <h> 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. <comment> was contained in earlier draft - already discussing whether it is really needed. <bill marshall> no extensions needed to COMET as result of san diego meeting and discussions on list. <h> not needed? <bm> 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.
<tom taylor> refer back to self to solve ringing problem has been proposed before but has problems. <jr> true
<comment> what if you have two devices trying to do simultaneous 3pcc on same parties - what impact does it have on held state entities. <jr> may be a problem if one is a B2BUA. Normally endpoint can't tell the difference between 1st party origination and 3rd party origination.
<comment> normal behavior is that if you send SDP-hold you get SDP-hold back. <jr> interferes with 3PCC. Need to work through services draft. Actually, after review of the call flows, not a problem.
<bill m.> problem seen was need to have 3rd party insert transcoder when it detects incompatible endpoints <jr> basic SIP problem, not 3PCC problem. Same as INVITE without SDP to begin with. <comment> proposes reINVITE to solve problem.
Issues:
1) subset vs. no subset - rfc2543 inconsistent on whether SDP in response is subset of INVITE or not. <comment> if no overlap will send 4xx instead of 2xx.<jr> 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. <discussion> problem transcends SIP, needs input from SDPng group. <jr> everything uses SDP differently. <discussion> incompatible with PacketCable in this and other ways. Should support most common models. Need to sync with SDPng. What is the default interpretation? <jr> trying to define normative text <discussion> need to define associations. We must first decide default - seems to now be that not sure subset is necessary?
<jr> The default is you send the codecs you can send/receive, and the response is a subset of that. <discussion> response does not have to be a subset of that.
<jr> 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?
<discussion> 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. <flemming> won't be acceptable since that violates base SDP spec. <discussion> need to be able to give B enough notion of what A can do, both uni- and bi-directionally.
<definition> presence of multiple codecs in SDP means can do them all simultaneously. <discussion> not everyone comfortable with this - want way to say can do codec 1 or 2, pick one, can't do both at same time.
<discussion> 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.
<jr> 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.
<consensus received>
<jr> then the response is the subset of those that party B can both send and receive <discussion> 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. <long discussion on asymmetric use of e.g., RFC2833> <chair proposes that no SDP changes will be entertained here>
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: <discussion> issues remain - will go to the list.
Notes from SIP WG Interim Day 1
9Feb01
entered by Dean Willis
------------------------------------------------------------------------
Multiple from Fields Early Media Transfer Out of Consultion -- geting Refer-To address to actual endpoint Bye/Also in BIS Draft Request URI Parameters -- allowed, unallowed, recommended Reinvite Glare -- overlapping reinvites Preloaded Route Headers (route on initial INVITE) SRV Randomization Issues
New open issues:
Overlap Dialing Message Header Length limits Time Stamp Header usage Unknown Provisional Responses (set at 49 to fix in BIS)
Discussion:
SRV must be deployed properly to get proper behavior in record-routed networks. Request that BIS include clarification that record route with transport other than UDP requires that SRV records be correctly implemented. The issue is that a proxy that changes transport protocols and doesn't record route may cause problems on reflective side.
Meaning of Call ID: Receive INVITE at conference with call-ID matching an existing call but with a different From: field. Proposal: follow simplicity, this is either an error or an all-new call leg. Argument: under 2543, this is legitimate behavior. However, call-ID has no conferencing semantics. This is not an error, just undefined. No objections to addressing on joins/replaces.
SDP Semantics: What exactly is SDP exchange procedure? Which messages can contain or must contain SDP? Consensus from 49 -- offer and answer, two cases, SDP in INVITE and OK, or OK and ACK. Discussion -- do we need to modify UAs that honor 3rd SDP in ACK to discard call? Rough consensus -- this condition is up the receiver to resolve, general rule to ignore. From 49, we are allowing 183 in SDP. How do we deal with this and the offer/answer model?
Early Media: Issues: send invite, get audio in reverse direction before call is "established". Since reinvite while invite in progress is disallowed, there is no way to modify the session parameters until the invite completes. Can't put early media on hold. Difficult to reconcile with forking. Early media may not match code it comes in (180 with fast busy). Requires PRACK. Eliminates possibility of sequential searches. Note: some kind of indication critical for ISUP mappings. Note: Callee-caller early media is one set of cases, caller-caller early media is another. Also case of reverse media with 1xx response. Case matrix developed in meeting. Point: difference between preparing to receive media before 200OK, and sending an early media stream before sending 200OK. There may be a requirement for an ability to refuse or squelch early media. Divergence into early-media and PSTN gateway interworking issues, . Action item: Adam and Gonzalo to clarify gateway behavior for pre-connect 200 vs early media in ISUP-interworking draft. Action item: Henning to includerecommendation against (should not) early media before 200 OK in BIS. Further exploration of early media to be devloped in later draft work. Discussion of manyfolks need for UI-semantic provisional response for "progress", aka 183. This implies a need for an IANA registration process for response codes and possibly methods. Action item: Henning to produce a IANA considerations draft for response codes and method names.
Timestamp header: Spec says reflect timestamp in response, but not which one. Why? For retransmit timeing, want to know RTT between client and server. This means only needed 100 resposnes. However there are other uses. Conclusion: relection of timestamp header mandatory in all responses in BIS. Action item: Henning add to BIS.
Message Header Lengths: 1500 byte limit exceeded frequently. Many implementations limit. What should spec say? Proposal: 1) SHOULD allow to 64k, 2) SHOULD allow any number of each header, 3) SHOULD allow headers of size bounded only by message size limit. Much debate about embedded, cellular, 5xx response codes, etc. Conclusions: Normative text about message size is a future problem -- not a good idea now. We want to put stuff needed to send response up front in message. May need a "minimal message only" mechanism for forward direction. Action item: Allison and Scott to take to Apps ADs and see if there are guidelines.
Multiple Froms/Sender: Conclusion: Future extension work.
Bye/Also Header: Some clients support now. Keep? Argument: whatever we decide to do becomes the solution. Proposal: remove Also header from BIS draft, consider obsolete. Somebody may wish to record history in separate draft -- Allison says may go directly to "historical". Action: Rick Dean to do informational record for history. Action: Henning to not include in BIS. Action: Robert Sparks to spank people who bring up Bye/Also on list.
Overlapping Transaction: Can one inititate a new transaction while one is in progress? What does it mean? Needed for some cases such as PRACK, COMET, INFO for ISUP. Proposal: 1) Allow overlapping transactions under specific conditions. 2) Final response for new transaction not dependent on final response for previous. 3) Transactions do not affect state of each other. 4) Can only do them once tags/route obtained from earlier transaction. Question: too general or hard to use concretely? Action: Unknown party needed to query list and see if anybody has done this.
close of notes at 1:30.
Meaning of re-INVITE without SDP:
Notes by Bert Culpepper, Day 2, 2nd session
------------------------------------------------------------------------
Interim meeting 2/9/01
Open issues discussion
Jonathan led the discussion using his list of issues presented at 49th IETF ( http://www.cs.columbia.edu/~jdrosen/papers/sipwgdec00_issues.ppt <http://www.cs.columbia.edu/~jdrosen/papers/sipwgdec00_issues.ppt> ). Most will be resolved in the bis. Those not resolved as of the last WG meeting include: Meaning of call-id, SDP semantics, overlapping transactions, multiple from fields, early media, transfer out of consultation, request URI parameters, bye/also, re-invite glare, pre-loaded route headers, SRV randomization issues, overlap dialing, message/header length restrictions
bug of handling of unknown 1xx messages as 100, this is a problem with 183. solution is to forward all unknown 1xx messages upstream. Bill's proposal is for all UAs include "proxy require: bis" header. Shouldn't be needed if default proxy behavior is to forward all unknown 1xx messages upstream. The bis will have this issue clarified.
Discussed record-route issue (including what transport is supported by next hop) being closed, Jonathan posted text to the SIP list.
Meaning of call-ID: issue-what is the meaning of a receiving an invite with a call-id that matches an existing call leg (but different From). consensus is it's not an error nor does it mean anything.
SDP semantics: issue-what is exactly the exchange procedure? consensus was that it's only to occur in two places: in the offer and answer. SDP in either INV/200 or 200/ACK.
Meaning of reINVITE with out SDP: (editor's note: didn't capture the consensus.)
Early Media: issues 1-no way to modify it once started, 2-can't transfer while on hold. 3- can't put media on hold. 4-problems with forking. 5-early media may not match the code it comes in (e.g. 180 & fast busy tone). 6-requires PRACK. 7-eliminates possibility of sequential searches.
The following table shows the problems that apply to the three cases where early media exist.
reverse media reverse+1xx
forward early media
can't modify once started can't modify once started
can't modify once started
forking (matching)
forking (bandwidth)
can't hang-up just one branch
requires PRACK
The bandwidth problem (caller can receive multiple RTP streams and not support combined bandwidth) introduces a requirement to be able to refuse a media stream.
The can't hang-up problem (caller can't CANCEL individual branches prior to final responses of a forked request) introduces a requirement to have a reverse message.
A reverse INVITE was talked about as a possible solution, a requires header will be needed for this approach.
Another consideration is with PSTN Gateways - they need to know when to send 200 OK vs. 1xx.
consensus: bis will say UAs SHOULD NOT send media prior to 200 OK, but not forbid it. There will be a separate draft for early media. ISUP I-D authors should update isup draft to discuss when gateways send 200 or 180.
Timestamp headers: issue-which response to reflect timestamp. The useful purpose of the header is in 100 for RTT determination. consensus: supply the timestamp header in all responses, specifically 100 Trying.
Message/header lengths: issue-1500 message limit exceeded frequently, implementations limit header or parameter sizes. Proposals are 1) to allow up to 64K, 2) should allow any number of each header (via, record-route), 3) should allow headers of any size (not beyond message size limit).
A recommended UA behavior is to put the important headers (those needed for response routing) up front. So endpoints can send an error response about the message being too big.
Normative text on max messages size is long term. May need a forward message indicating max supported length so proxies can gracefully "refuse" request or not record-route if doing so will result in message length exceeding that supported by the UA.
multiple from fields: - conclusion: future work, will be a SIP extension.
BYE/Also - has been removed from bis draft, the consensus is that this is deprecated. May be documented in an information I-D that becomes a historical RFC to support existing implementations that use it. New implementations should use REFER. Rick indicated he'd put together this draft. Robert Sparks will take ownership of this issue on the SIP list.
Overlapping Transactions: issue-can a new transaction start while one is in progress. Proposal: allow overlapping under specific conditions, 1) final response for the new transaction is not dependent on final response of the previous transaction, 2) transactions do not affect state of each other, 3) can only do them once tags/routes obtained from provisional response of outstanding request. It is thought sending a request prior to completion of a pending request should be OK under these condition for most methods. Exception is the INVITE method. Could be a problem for other methods if CANCEL is used with the method (since specific request to cancel can't be determined if more than one is pending). Action: need to find out if anyone implemented CANCEL for any method other than INVITE before documenting the resolution.
Agenda
SIP-H.323 Interworking Requirements
3GPP and SIP
SIP Events: Changes and Open Issues
REFER Issues and Call Control
Diagram
3pcc Update and Issues
Making SIP NAT Friendly
Overlap signalling handling
SIP Extensions for Caller Identity and Privacy
SIP WG Open Issues
SIP Extension for Multilevel Precedence and Preemption (MLPP)