IETF SIPPING WG (Session II), THURSDAY, Nov 21th, 2002. Reported by: Vijay K. Gurbani IEPREP in SIP, Henning Schulzrinne draft-ietf-ieprep-sip-reqs-01 Document in LC. A protocol reqs I-D; meant as input to SIP WG. Overview: priority allocation for VoIP systems which bridge into a switched circuit network. Needed for emergency telecom systems. Typical user is an government employee, not normal citizens. Resources: trunks, CSN resources away from gateway, IP network resources (out of scope), receiving end system resources, SIP proxy resources. Network assumptions which figure into the solution space: full control network: you can modify anything transparent n/w: can't mess with many n/w entities but can assume that the n/w is nice to use, no (or less) packet loss SIP/RTP transparent: no guarantee that n/w you are using lets any ports out, but SIP calls can go out. You can make regular calls using SIP/RTP. Restricted SIP: restrictions on what is allowed -- walled garden type of networks (e.g. 3G or similar such networks). ; reached consensus on all in the ieprep WG. Tried to be as much as non-specific to any scheme. ; have elevated sensitivity since the damage someone can do is substantial. NOT related to 911/112 calls. Also, if priority is desired, destination already idenfies such calls. Changes since -00: clarified proxy role; added n/w configurations and their resources (CSN-to-IP), ... Next steps: IEPREP WGLC right now. Would like to get some feedback on what is the next step. This is the first time that SIPPING has got a req document from somewhere else. Rohan: We have gotten reqs from someone else (3g), but first time from another IETF group. Rohan: Let's get some ideas from the floor; otherwise, I would follow the same path as we did for 3GPP. Difference would be that this document does not have SIPPING change control, it is a IEPREP document. Dean: What are the specific reqs to SIP? Does this draft bring out those reqs to SIP so we can take it to SIP WG and ask them to meet them? Henning: Like to see this not be something that will sit for a long time in SIPPING. Would like to put it on a somewhat short fuse. Can we schedule a WG LC? ROhan: We can schedule a review. Henning: Good, so I can fold in any additional reqs so ieprep does not object. Cullen: It is not clear that all reqs are going to require mods to SIP. Jonathan: This is closer to Request-Disposition. Henning: Generalizing the problem. We have 3 properties caller or calling station properties: e.g. 'operator', 'prison', sip:jfk-gate17-phone3@payphone.com callee or called station properties (registration, caller prefs) call properties (priority, resource priority) We may want to clarify what we are expressing as a general class of things. Dean: This will go forward, we will do a review of a document and provide some guidelines. Henning: We do not want to create a new architecture; this idea works in PSTN right now without any new architecture. We do not have to build anything for this to work. ??: Can we have the work be posted to ieprep? Rohan: We do not do cross postings; can we have a volunteer who would do that? SIPPING Conferencing Design Team, Alan Johnston There is a now small DT to make sure that all conf related documents get back in schedule and agree with each other in terminlogy and usage. Each team member is responsible for >= 1 document. Planned documents: You should expect to see a new version of the framework document first. Will be out shortly and have agreed upon terminlogy. Status: we have drafts of some of these documents; we do have agreement on terminology and scope alignment; we also have plans for regular DT conference calls and plans to report to WG chair and list. We are making good progress on this notwithstanding the plethora of current documents. Rohan: Anyone has serious concerns with this process? Eric B: Maybe nice to have docs out a month before next IETF. Rohan: 6 week target is much better. Media encoding DT, Gonzalo Camarillo Goals: we are going beyond the reqs for the deaf; we are working on invocation of services that involve media manipulations including codec and language transcoding. We want to be opes aware. Deliveries: transcoding services invocation in SIP and the source and sink attributes for SIP (2 I-Ds) Possible future deliveries: labelinvg of transcoded media streams, caller prefs extensions. We have to think about these two before finalizing them. Open issues: invocation in the B2BUA model as opposed to 3pcc model. 3pcc model quite complete. We use Route header field as if the B2BUA was a proxy. We did not feel comfortable with this approach. Maybe we can use something else like message encapsulation or REFER. Current decision is REFER: more opes friendly and has security built in. Disadvantage: more signaling. But generality wins. Gonzalo: If we have not, I would be willing to add them. No problem. Keith D: If we are going to solve a general problem, we have to see if there are more general reqs. Open issue in plumbing draft Is this needed at all? Jonathan: I am not in favor of this document. Not clear to me why the service covered here cannot be done in a more general fashion. Gonzalo: let's see a couple of scenarios: Jonathan: this complicates the issue even more and encroaches on conferencing work. There is some overlap. Rohan: It is related Eric B: This may be interesting input to the conf DT Rohan: Fine line diffrentiating this from conf work; conf implies some sort of combined media effect, this asks media to move to various places, but not be combined. Gonzalo: 2 conclusions: co-ordinate with conf DT on overlap and ask SIPPING WG on further path. App Interaction DT, Jonathan Rosenberg Small team -- 4 members. What are we doing? Stimulus with SIP -- the way in which users interact with apps using media, markup and dtmf. We are making good progress on understanding the nature of dtmf in these networks, but there is a general problem here: event reporting. Produced 3 documents (framework rosenberg-sipping-app-interaction-00, Burger KPML I-D, Jennings app-info I-D), and inherited 1 (culpepper- sipping-apps-interact-reqs). Open issues: infamous SIP vs HTTP debate -- who carries the information? Document clarifies difference between rfc2833 and using SIP or HTTP to carry these. It deliniates the UI from the app. Eric: If you have markups that assume HTTP they will use it; if you have markups that assume SIP, then they will use SIP. The language construction is different. Focus determination for KPML: when a user enters a digit, which KPML amongst the ones from various apps does it apply to. Current draft says send it everywhere -- same as PSTN does. Architectural solution: have a central controller model which runs a super app and make decisions for the user. Is this adequate? Any other ideas? Error reporting for App-Info: what if App-Info URI is invalid? Options: no error reporting, only send App-Info in requests (where a error response can be generated), error reporting URI (infinite recursion problem). Related issues: indicating script termination -- should we or not? framework has feature that allows IVR barging to be pushed to endpoint. Problem is how to detect when its OK to start playing media again? Need some media synch. Market bits -> don't work; PT changes -> may work; others? Rohan: PLease read the draft and have more discussion on the list. Q.SIG, Jon Peterson Some interest in going forward with this in Yokohama IETF. Not a lot of discussion since then on list. From yesterday's SIPPING WG, we would also prefer to do some SIP->Q.SIG mapping. John Elwell has released a new version of I-D since Yokohama; changes: use of P-Asserted-Identity in mapping to CLIP/CLIR and strengthned security text following the SIP-ISUP draft. Not a SIPPING WG item yet, any comments? Keith: Minor nit: it is QSIG, not Q.SIG. Rohan: Any objections to make this a WG item? Pekka Pessi, SIP, iCalendar, and iTIP iCalendar is a calendaring information exchange format based on vCalendar. iTIP is an abstract protocol for interaction between calendar UAs. Methods like PUBLISH, REQUEST, REPLY, CANCEL, ADD, etc. iCalendar use with SIP: off-line invitations, describing SIP tele- conferences, indicating schedule and timezone, notifications for schedule, conference, etc. Map iTIP to SIP ==> iSIP. iSIP is very similar to iTIP. OPen issues: does iSIP fit in calsch? Does not change how SIP is used. Submit new draft using standard iCalendar format? Specify iSIP apps separately: iCalendar for on-line conf? Eric B: Why do we have to carry this in SIP? Pekka: SIP brings SIP addressing Jonathan: One model is that this is some MIME type and I don't care. Then why do we have to define a mapping if we are carrying an object? Rohan: Yes, it is an object and you don't have to do anything in SIP. However, some protocols provide optimizations for carrying the object. [15:55 adjourned]