SIP WG Session 2 Wed. 1300-1500 1. SIP Caller Preferences Jonathan Review of content: caller allowed to specify call features. - rules for which UAS wanted - request handling features - UAS can register characteristics of URLs - proxy handles by doing string matching operation (doesn't have to understand semantics) Changes since last version: - new options tag format - added no-ring request-disposition - added numeric service tag for numeric pagers - discussion of CPL interaction Open issues: - relationship with CPL: has description now - how to reconcile conflicts between CPL and this: let proxies decide -- view both CPL and caller preferences as hints -- per Scott P, recommend that caller prefs take precedence - syntax for capabilities: conneg? - IANA procedure for registering new capabilities -- Joerg suggests we may wish to impose constraints or require documentation - what additional capabilities should go into the baseline spec? Question: interaction with DCS no-ring proposal: Jonathan sees the situations as different, KK sees possibility of overlap -- more consideration needed 2. SIP Session Timer Steve Donovan steven.r.donovan@wcom.com Call stateful SIP proxy -- various reasons for it to operate this way Problem of resources left stranded by message loss. Add concept of session time -- not same as request timer new SIP-expires header and new 4xx response code. Example call flow -- negotiation of session duration. Agreed in Oslo to proceed -- is this still consensus and is it baseline or standalone? Jonathan: criteria for base spec.: does not work as a SIP extension (i.e. potentially ignorable) Consideration of how proxy determines support if header not used. Added Supported/Unsupported headers to base spec, so that issue is solved. Suggests this should be separate. Agreed. Steve pushing for last call ASAP. 3. SIP 183 Session Progress message Steve Donovan Needs: - for PSTN interworking -- sorting out sort of ringback -- definitive mapping with ISUP ACM -- ability to have media session setup before net-to-net charging - need to guard against early media sessions which never complete - other uses proposed Various proposed solutions. Shows procedures for PSTN interworking. Proposed extensions: - full SDP bodies in 1xx messages - add 183 Session progress with behaviour - definition of 180 and 183 headers relative to ringing Dependencies: - need reliability of provisional responses for PSTN interworking - definition of required, desired, .. ... Next steps: standalone vs. baseline? Suggested to separate some functions. 184 Early Media --further discussion on list. 4. Interdomain IP QOS Henry QOS needed, but available only if payment assured. Draft suggests possible interdomain message exchange using existing protocols. SIP, OSP, COPS, RSVP Reference model, call flows -- 46 steps to setup through final ACK, 29 steps to teardown Looking for suggestions on alternative approaches -- queries on choices -- simplifications -- use best effort QOS for ringing -- WG effort? David Oran : how can SIP proxy know which router to go to -- media path not same as signalling path? Problem both with DCS approach and this one. No real answer here -- ideas wanted. Jonathan -- jumble of protocols suggests trotting through a series of WGs. Not a SIP item because no SIP changes proposed. KK: community of interest in same problem. ??: could this be added to the call flows draft? Jonathan: joint WG meeting? Probing for working method Steve D: SIP impact: when to trigger QOS? Could use extension for this. Lawrence: ??: real customer problem Looking for recommendation on how to continue work. 5. SIP For QOS Paths Mark Gibson mrg@nortel J.Crowcroft@cs.ucl.ac.uk Assumes core network running MPLS with CR-LDP Core mgmt layer interacts via COPS SIP with added route header used to communicate across Mgmt layer to probe for paths Questions: why use this instead of RSVP. Answer this can force different routes. 6. Uses for Info message Kuthan --- Transport of GSTN messages Transport of DTMF - to serve existing IVR applications until they are replaced by WWW - reliability, security advantages over RTP - difference in signalling and media paths Advocates text encoding to be consistent with mgcp/megaco Dean: notes that application-level validation of digits often desirable. Scott: various situations where RTP transport of DTMF justified, particularly, could get different kinds of behaviour with alternatives. Inter-digit timing can often be a key issue. 7. Providing for multi-proxy authentication of a siP request RoberT Sparks MCI-Worldcom multiple proxies, in different adm domains along a signalling path, may wish to challenge a request. Not clear from current draft how this works -- challenges get lost. Proposes to modify proxy UAC behaviour to remember challenges and respond to each -- proxies to check responses for those pieces applicable to that proxy. Problems -- how to break cycle if some proxy doesn't support this behaviour. -- proxy must be prepared to accept multiple responses to same challenge jonathan remark -- may get behaviour for free -- problems -- parsing multiple field values in same header -- proxies can challenge with multiple choice of schemes Jonathan surprised by this possibility Basic item: comment-separated nonces. Question: how does hop-by-hop vs. end-to-end auth. work with multiple proxies? - not thought about - good list discussion point Jonathan note: base spec. item. 8. Host Mobility Management Protocol Faramak Vakil Presenting prelim specs. Involves extensions to SIP Propose HMMP as work item for mobility mgmt Architectural diagram -- circuit switch modes present as well as SIP HMMP runs on top of SIP - domain hand-off - subnet hand-off - cell hand-off left to link layer -- technology dependent Spoofs constant endpoints for TCP apps and supports TCP as is Walk-through: during transition from cell to cell, for short time have replication of data through both routes to ease transition Inter-domain: need wildcarded register. Other wise like inter-subnet TCP -- "SIP eye" keeps track of mobile user and updates TCP bindings as required. Needed from SIP -- Info method' -- REGISTER to designate "RHO contACT" -- SIP UA has SIP_EYE agent to keep track of TCP -- SIP UA understands address binding INFO messages Disposition: chairs to consider offline Concern from ?? re 3GIP refs. in presentation Progr SIP services in JAVA SIP servlet API Anders Kristensen HP Java extension API for SIP servers similar in spirit to HTTP servlet API Server matches incoming msgs against local rule to decide which servlet to pass msg to API gives full ctl of SIP msg handling to servlets Servers can choose whether to apply sandbox security model Benefits - - perf - no forking, servlet sharing - safety of Java - convenience - high level abstractions, tight integration w/server -- logging, security, location DB - lifecycle model etc Key avstractions SIPServlet SIPServletContext SIPFactory ContactDatabase SIPTransaction SIPRequest SIPResponse example: RejectServlet Jonathan: lots of interest -- APIs not typical fcn of IETF. Need offline consultation. Scott B.: rare for IETF -- hard to decide which to work on (WINSOCK vs ...). Couple of examples (GSSAPI, SIGTRAN), tend to avoid -- esp. stds-track. Some very solid resistance. Abstract API more acceptable. Jonathan -- will start up interested parties list, announce on SIP list.