RAI Dispatch meeting notes Notetaker: Christian Martin 1) Administrivia, Agenda bashing Status SIPSCOTCH tel epresence tel URI VIPR tel epresence ad hoc 11:5-13:00 No objections to agenda 2) SIP Session ID Hadriel Kaplan Session ID needed for end-to-end diags (B2BUA change call metadata) Force call ID to stay infeasible Propose creating new "Session ID" attribute Keith: We should be very specific about its use Hadriel: We are specific in the draft about usage Christian: Should this be abstracted to an end-to-end "meta" layer of which one is a session-id Marshall: Is this a nonce in principle? Hadriel: No Unknown: Do we really need an ID for troubleshooting exclusively? We can map call-id's hop-by-hop Hadriel: I disagree - end to end across domains, troubleshooting is almost impossible without massive coordination, retrieval of CDRs, etc Jonathan: Why not use same session id for conferences Hadriel: individual legs sharing fate, but not session info Jonathan: What about session id collision (deliberate) one-twenty-eight number is fine, WG is a good idea to flesh out info, take a humm (a few people against) spencer dale peter christian john hadriel laura keith Robert - call parallel fork two dialogs, same session-id, not fate shared, we need to get scope clean cullen: does anyone have a problem with vendor implementation differences spencer: 2 years, and only a header has been produced on the list? use the wg Mary : seems to be a scope issue Darryl: new header, B2BUA doesnt support a draft, can overwrite or delete session id Simon: sip devices working group might be useful Mary: Chairs don't feel consensus on scope of work Cullen: we can schedule time to discuss on the list : thought we had consensus Cullen: Any discussion should be about the charter 3) Telepresence Keith: this work builds on work from where? Isnt work in xconn sufficient? I'd like to see something explicit before charter Allyn: WG will determine if there is existing tech available Keith: I'm not convinced this shouldnt be done before charter John: Charter doesnt show protocol work, so ok. Also, maybe less drafts, informational Ronnie: we do need time to identify Harald: Virtual worlds protocol in apps area may be useful Stephan: TIP - public statement? Allyn: TIP is Cisco's protocol - given ownership to IMTC. IMTC has started a working group in TIP Steve Botzko: TIP doesn't solve all the problems we have presented here (Continuous presence, as an example). The work here is to generalize a solution Jonathan Rosenberg: Sounds like standards shopping (looking for a WG) Cullen: Does Cisco have any interest in submitting TIP? Is that where the confusion is Jonathan Rosenberg: What if it goes to IMTC and IETF does it's own standard? Allyn: TIP is what we use now, but we will use whatever is produced here Steve: Intent in IMTC is to not change TIP. No one is supporting TIP in any new SDO Jonathan R: IMTC may or may not agree that it is an SDO, but they own the document Mary: Let's stay on track. Stephan: Reason for bringing TIP up: Yes TIP is on IMTC now as required, but there is still a conditional patent license that hasn't been transferred. It would be better if the solution deliberatel y mentioned that TIP would not form the basis Allyn: sounds fine, we have no problem Brian: What are we doing here Allyn: Can we have a decision? Mary: We need to update the charter so we can get approval for a new WG, Include Cisco TIP statement and other work Unknown: IETF and ITU-T split? Would it be parallel or separate. Steve: ITU-T SG-1 charter for tel epresence includes other info. Includes work from IETF (same issues typically with ITU). ITU working on H323 and SIP GWs, IETF only SIP Cullen: Do you see work here like room geometry, etc (not just ITU.IETF specific "features") Steve: ITU should reference the work here Marshall: Keith mentioned xconn, I would suggest discovery of external protocols should be part of it Ronni: ITU and IETF. IETF will do the protocol, ITU the "service" Stephan: IETF is lousy in overal system and service design. ITU is lousy in protocol design, IETF better. ITU will likely profile what comes out of here, but IETF will do protocol design Mary: Keith, clarify what you meant regarding other work? Keith: A WG really is about defining a new protocol, we should do the discovery before the charter Brian: Seems that this work is too open ended. Problem I have, least well specified in dispatch in a while James: Agree with Brian Jonathan: Looks like a standard problem and a standard solution. James: Feels more like there would be a guidleline rather than a "standard" Ronnie: Just because multipoint, people mentioned xconn Steve B: Current charter can be used for developing the framework, then we could recharter to dev a protocol Mary: We need to tighten the charter Allyn: We were advised not to be more specific Mary: Pick up in Ad hoc 4) tel URI enhancements John: Is DAI only applicable to tel URI? : Use case in draft only specifies Jonathan R: This work has been killed for three times. It is architectural wrong. Pulling PSTN parameters into tel URI. Architecturally flawed. Put it in a header. tel URI is not the place. Not standards track work in its existing form. Brian: I need this stuff to happen, but we need to preserve semantic integrity. We don't need DAI "reasoning" as much as the data in and of itself. Jonathan: We already have ways of tunneling in SIP Jonathan: Are you sure this is only an ISUP-SIP/tel URI parameter? Brian: I have a CPC/OLI Jonathan: Is there a use case where ISUP is not the originator Brian: In my case, always one end that is ISUP GW Keith: DAI is only used for dial around requirements? Jonathan: Every call terminates only on PSTN? No way. John: Solution can be encap or translate, but seems that we keep using encap Paul: All the trust/security relationships are rarely proposed in these areas. Adam: Doesn't go in the tel URI. History info can leak info. Don't piggyback on URI Jonathan: Fix the document! We keep going over this! Cullen: So we agree this shouldn't be in tel URI? :) Mary: Brian has the action to document the use case Brian: Somehow we need to create a charter of some WG to solve this problem Keith: So going forward depends on IANA registration. So if you go forward, depending on whether standards track or informational, will dictate Jonathan: If you're interested in a standards-based protocol, this method must die, we start a new effort using a header, etc. So if you want a rubber stamp, make informational RFC documenting current implementation. Keith: No one wants a rubber stamp. 3GPP even doesn't need it 5) VIPR Bernard: are the security properties or anti-spam properties lessened if PSTN core is replaced by SIP trunks Cullen: If you're willing to pass calls across insecure media, then yes Jonathan: Security properties are based on the fact that there is a public provider who is incentivized to limit spam. A lot of the security issues are around the fact that there is a charging model Jonathan Lennox: If you can watch a PSTN call, can you spoof on the DHT? Cullen: yes Edgar: Conflatng two sets or properties, but PSTN routing and confidentiality properties are not the same as timing and call duration Dale: Figuring out call start stop times isn't that hard John: This isn't going to protect you from getting spam from large governents, etc, but for many applications, this may be enough of an incremental improvement worthy of solving the problem Ronnie: We should move forward on the charter David: Generally like the idea here. Q: Chartered text has changed a bit, but, do you picture this WG to eventually cover asserted identities in the DHT cloud. Can the phone number "owner" somehow assist in validating the number somehow? Hadriel: Are you worried at all about what pandora's box you may open with communicating with non-Cisco devices Edgar: I on't agree with the threat scenario at all Should this be in sip peer2peer with a recharter Cullen: Interesting idea hum passes unanimous support