SIP WG Session 1 Mon 0930-1130 1. Announcement of SIP bakeoff. 2. Agenda -- no comments 3. INFO method -- Steve Donovan steven.r.donovan@wcom.com SIP charter item For PSTN interworking -- carrying mid-session signalling information Could be used for carrying other mid-session info -- encoded DTMF digits (controversial) -- event notification Slide shows over a dozen ISUP items to which INFO method would apply -- more could be added. Proposals for extension: -- addition of INFO request Question whether Required: header needed and INFO tag Next: whether INFO method a standalone draft or integrated One more draft update. SIP WG Last Call 4. Issues on the List -- Jonathan jdrosen@dynamicsoft.com (a) Supported/unsupported/desired CANCEL vs. BYE Content-Disposition vs. Content-Function Supported --------- Problem: how does server ask for a feature? Listing all supported features unwieldy Number of round-trips required to negotiate features Response contents to avoid loops Reviewed possible solutions -- Desire header vs. Require only -- latter forces extra round-trip Discussion requested Possibility noted to added qualification to Required header -- Q-value or tag like Megaco o- prefix. CANCEL vs. BYE -------------- Problem: want to hang up before receiving 200 OK CANCEL or BYE? Issues: before 200 OK, no route established. BYE may not reach same set of recipients as INVITE -- proxy behaviour not fully constrained. If BYE forks, don't know if all necessary recipients got it. Complications: may need end message to contain a body (ISUP). BYE can have a body, CANCEL cannot. Question of whether body needed. SIP-BCP-T: don't allow forking, so BYE is always feasible. Note that ISUP can always bail out if necessary -- body not essential. CANCEL is a hint -- have to be able to deal with 200 OK if received afterwards. Rule should be to send BYE to any call not remembered. Content-Disposition vs. Content-Function ---------------------------------------- Problem definition: - bodies have many potential uses - MIME type not enough to know intent Should we reuse the Content-Disposition header? Author not present, no comments. 5. ISUP MIME Type, Eric Zimmerer -- ISUP MIME type, INFO method, mapping TT noted -- need version for ISUP MIME type TT raised question -- whether instead of current duplication of effort in IETF, ITU, should there be protocol for specific purpose of ISUP transport? --- JR: don't necessarily know where call is going -- MIME a good solution Deficiencies: overlap signalling, continuity testing Interoperability of versions -- punted to the list Comment -- concerned that we are not aiming for ISUP forking Where does this work go? Jonathan: call for comments on carrying work forward here Lawrence -- two pieces of work -- extensions, profile Michael R: static view of ISUP transport or use SIP potential? In former case, don't need SIP. Eric: start with static view, then grow into more sophisticated view. Hence start with SIP container. Christian: interaction between static, dynamic interesting. Hum called on whether interest in working on ISUP transport, with view to exploiting potential of SIP. Consensus to do so. Chip noted "BCP" is a bit premature. 6. Camarillo draft Architecture: SG-MGC-MG architecture. Draft concerned with interworking between MGC and a SIP UA. Draft deals with message flows for calls in both directions, parameter mappings. Proposal that advanced ISUP feature mapping can be vendor specific -- standardization only on basic aspects. Accordingly, draft is based on Q.767 rather than Q.763. Issue of coordination of work on mapping, references used. Legal requirements have to be made clear. No comments or questions. 7. qsiG Transport -- Mo Zonoun presenting What is it? -- Suite of protocols between PBXs -- peer-to-peer, feature signalling. What is needed? QSIG transport BCP, MIME type Showed call flows, various examples. Henry comment -- could the various drafts here be unified? Jonathan -- interworking difficulties not so obvious with ISUP, because of QSIG vs. SIP feature interactions. Interested in working between telephony and non-telephony endpoints -- QSIG transport less likely to be general-purpose because of its more direct conflict with SIP role. David Oran -- QSIG in H.323 led to trouble -- customers ended up requiring H.323 awareness of some features. WW -- ISUP, QSIG should have similar solutions Christian -- reinforces point that this collides directly with purpose of SIP. MIME types for ISUP, QSIG should be unified. QSIG interworking a separate issue -- no opinion on working. 8. Johnston SIP telephony call flows Two drafts -- call flows, service call flows. Text diagram versions forthcoming. Goals -- illustrate use of SIP, stimulate discussion of telephony issues, drive toward standard interoperable SIP telephony implementation Listed document contents. Next steps: improve documents, looking forward to reissue in January. Contacts: call flows - Johnston, services Sparks Jonathan: thanks. What to do with it? Proposal: Info RFCs including this and corner cases from bakeoffs. Accepted by hum as WG work item. 9. IN App support of SIP/SDP architecture Haerens? Alcatel Aims: IN infrastructure independent of the IP signalling protocol (SIP/SDP, H.323) SIP servers: redirection, proxy can both be supported by IN Introduce idea of softSSF = SSF + CCF mapping Extended GK = (SSF + CCF mapping) + SIP Proxy Stack implications. Architectural: Potential I/F and protocol between the softSSF and the SIP Proxy Orig. and term proxies must be call state aware. - - Walk-throughs: Registration process, origination with IN interaction, termination ditto Comment: strong overlap with SPIRITS work. Response: consider here too to fill in gaps such as registration. Jonathan: similar to Lucent proposal to IPTEL last meeting. Are they the same proposal? Response: should combine efforts in SIP. Jonathan: feeling in IPTEL that IETF lacks IN expertise -- not appropriate forum. Do people feel any more confident here? Dean: discuss on list. Paul: argues that this is equivalent to ISUP mapping work, only this is for INAP. Lawrence: isn't this being covered in SG 11? Architecture good. Mapping should be done in ITU but latter may not understand SIP well enough-- is contribution being submitted there? Mapping to INAP really should be in ITU/ETSI. Chip: what is being asked of this WG? Response: need enhancements in SIP. Chip: what forum would work protocol between softSSF and SIP Proxy? Response: not on table for now. Basically want this group to work on SIP enhancements. Remark: third-party call control being worked in IPTEL too -- CPL. Question is why multiple ways. Jonathan: IN approach has value -- fails in different architectural contexts. Basically more alternatives are better -- each has its own strengths and weaknesses. Can discuss how to work this approach with SG 11. Paul: appeal to installed base. Note: INAP CS3 not specified yet.