DATE/TIME: 2005.10.08 21:00-22:15 NOTE-TAKER: SHIDA SCHUBERT MEETING: TISPAN AD-HOC NO of ATTENDEES: approx. 80 * Agenda ************************ 1. Summary by Cullen 2. Blur 3. Martin's presentation 4. Next step 5. Miguel's presentation ********************************* ********************************* 1. Summary by Cullen http://www1.ietf.org/mail-archive/web/sipping/current/msg09900.html ********************************* ********************************* 2. Blur --------------------------------- - We will talk about ETSI TISPAN stuff.(Dean) - Expressed that work on the requirement has been progressive but not necessary successful.(Dean) - Talk will be made on where the WG will go next with this.(Dean) ********************************* ********************************* 3. Martin's presentation -------------------------------- [Martin presented a presentation slide] * 1st slide on Voice Services - After reading the TISPAN doc, took the service requirements and broke them down.(Martin) - Voice service needs certain capabilities to meet certain needs.(Martin) Things that drive these needs.(Martin) > Regulation > Customer demand - Ironically, items required by regulators are also items wanted by parties outside of TISPAN.(Martin) - So it becomes not why but how to accomplish providing these services.(Martin) ------------------------------- * 2nd slide on AR - Explained his analysis on the requirement. - ACR - Needed to indicate the caller that call was rejected due to lack of identity in the call(due to anonymous call).(Martin) ------------------------------- * 3rd slide on Resolution - Martin presented solutions - Status code. - Terminating network has knowledge about call failure was failed due to ACR and invokes/play network announcement.(Martin) - This is provided in N.America.(Martin) - I believe we moved the override of the ACR, so itfs no longer in the req.(Keith) - We discussed this extensively on the ML. We don't expect any protocol extension even if the feature is required.(Miguel) - Jonathan submitted a draft, itfs in archive this morning which achieves this by specifying a new status code.(Cullen) - Itfs submitted.(Cullen) - It has everything from IANA registration, security consideration and everything. Itfs meaningful within SIP as well.(Jonathan) - It seems like it was hard to get any status code until now.(Keith) - Are we happy to with this path?(Keith) - Is it a done deal then?(Keith) - Does anyone object?(Jonathan) >> No-one objectedc - Robert is going to do analysis of how many codes are left.(Rohan) - If we have enough status code we can do it.(Rohan) - As for CPC stuff, there was a discussion at SIPPING to deal with it with SAML.(Dean) - Rocky will tackle the draft to see if it's possible to do it with SAML.(Dean) ------------------------------- * 4th slide on Terminating Party Indication - Mechanism for relaying the identity of the terminating party. - Information allows the calling party to call the callee directly. - End result to this will be the conclusion about the connected-identity. (Martin) - Some of what is said in the requirement differs.(Jonathan) - Identity in the reverse direction is not supposed to be asserted network. - It's in contrast to what's been proposed. - Call back number can't distinguish the instance but person is what the requirement states, so there is a contrast to what's written there about GRUU.(Jonathan looking at the slide) - What does terminating mean, when 183?(Jon) - Is it somebody that response back or somebody that you end up establishing the session with?(Jon) - It's the party you establish the session.(Martin) - Is sip identity considered a identity provided by the network?(Jon) - Distinction needs to be clear.(Jon) - Ability to call back terminating party in the future, is it a MUST? (Steve) - Some people/enterprise(800 number) prefers not to reveal the identity information.(Steve) - It should be MAY(Steve) - Use-case for this is, when one for example, reached a user using extension number through PBX, with this feature the caller can later, call directly without worrying about the extension.(Miguel) - Want to talk about identity privacy(Jonathan) - If there is a requirement, where one wants to provide a reachable contact while hiding the identity, recommend to look at the draft-rosenberg-sip-identity-privacy-00.txt(Jonathan) - It also fixes the annoying spec in RFC3261 Which states that call is anonymous when display name is anonymous. It's bad to desire context to display name.(Jonathan) - We had a situation where anonymous was miss spelled.(Jonathan) - Explained how anonymity should be provided in the draft.(Jonathan) - Take a look at it, itfs necessary for this sort of stuff.(Jonathan) ------------------------------- * 5th slide on Call Waiting - It talks about network service.(Jonathan) - It's terrible to provide call waiting it in network with SIP, everybody knows this.(Jonathan) - There is a requirement that there is an indication that there is another call coming in.(Jonathan) - If the output is to be sent to the TISPAN, it should say that it should be done on the client.(Jonathan) - I was shocked when I saw this.(Miguel) - The service is called Call Waiting but it's not really call waiting. (Miguel) - It's for network to acknowlede user's state of call. - Things it needs to be aware of is maximum no of on-going call. - At the moment itfs about counting the number of calls.(Miguel) - What you just said is not articulated in the document.(Dean) - Output on this would be "Gee that's unclear can you work on it a little bit more?"(Dean) - Outcome for this debate shouldn't simply say clarify the req.(Jonathan) - While there is an incoming call, telling the user what they can do is not a good idea, if you want to do something like this just send them INVITE.(Jonathan) - What's in the requirement is not so bad, it's the title that makes it confusing.(Keith) - They didn't sound like requirements.(Rohan) - There needs to be a higher level requirements.(Rohan) - More we talk about them more weird they sound.(Paul) - Notion of limiting the number of sessions is okay with black phone but it does not make sense with IP phone.(Paul) - Sounds like the conclusion is to send back and ask them to help us understand.(Jon) - I would suggest to move to the next requirement we don't understand the requirements.(Hannes) - CDIV - It was addresssed at the SIP meeting today that the voice-mail draft will address the requirement stated on the TISPAN requirement draft. (Martin) - CPC/OLI - It was agreed to look at it using SAML and try to write the draft.(Dean) - What information in CPC is actually used as well as how they are used needs to be clearly identified.(Steve) ------------------------------- * 6th slide on Malicious Communicaton Identification - Explained the requirement. - It's about being able to mark a malicious call. - Donft think need a new protocol spec.(Martin) - May have a button that sends an indication to the WEB server.(Martin) - The requirement is to mark the caller.(Miguel) - The identity-privacy allows identity that's anonymous but traceable(return routable).(JR) - It's not just the last call that you want to report. It could get expanded to include non-last call.(Keith) - The requirement is about the last call, no expansion and there is no mentioning of sucha a thing as an encryption. - Suggestion is to deliver the bit that marks the call with call information.(Cullen) - How they pass identity around is with P-A-ID - Need to clarify what the last call is.(John Elwell) - What about if there is call waiting? Which one is last call?(Paul) - Not a protocol requirement, it's a UI requirement(Jonathan) - So the requirement should say the logged call is to be marked.(John) - Need to do it in SIP, you need to be able to mark the call.(Miguel) - What do we need to do?(Dean) - Requirement should say that it should be able to provide a marking on a call that was perceived malicious.(Keith) - It should be a device requirement that can store enough call, select the call and send it to web server, which marks the call. (?) - There is enough info on the device to correlate the call.(Martin) - There is enough info to identify the call.(Jonathan) - What about a phone without UI such as a black phone?(Paul) - It's somebody else's problem that phone doesn't have UI.(Jonathan) - There is a requirement, for ability to request identity upon request even if it's unavailable in the signal.(Miguel) - These services don't always work. Why should we have them work 100% of the time?(Martin) - We are providing the information that's needed to retrieve the identity.(Cullen) - But there needs to be a way to extract information.(Keith) - Can't extract something from SIP when it's not present in SIP but only present in PSTN.(Cullen) - The logging system can query the GW or some entity that's able to query and retrieve the identity in PSTN.(Cullen) - What does AOC mean?(Martin) - Actual cost? Estimated call? Identitification of the call type? - App-interaction framework can be used to do exactly something like this.(Jonathan) - May need to look at the requirement a bit closer.(Jonathan) - Recommend to have a look at app-interaction framework.(Jonathan) ------------------------------------ * 7th on slide: Call completion - Explained the requirement.(Martin) - It reads like presence with dialog package.(Martin) - I think can accomplish this with presence and dialog package.(Jonathan - Itfs really hard to make it work. - In PSTN has one phone, once you have more than one phone on both sides, it can get agly. - My suggestion is to do a phase approach - Using dialog event package is a little bit better than how it's done currently.(Jonathan) - Queing is hard.(Jonathan) - If application server is used then no extension is needed.(Keith) - To emulate the service we need to define an extension to manage the que and to send one NOTIFY at the time.(Jonathan) - With B2BUA that we have we can do that.(Cullen) - If dialog-pkg is only used for CCBS/CCNR then it would work. But other wise it won't work.(Jonathan) - Itfs impossible to provide identical solution considering the complexity that we need to face.(?) - We donft want the server in the working point, want to put it anywhere we want.(Keith) - Donft think itfs an application server. Application server is the presence server. What's needed is the queing mechanism (Jonathan) - Suspend/resume is nasty.(Jonathan) - If application server can interact with the presence server it can work.(Jonathan) - It's sufficiently complicated that we obviously need a design task.(Dean) - Need to find out whether we need to tackle a scenario where there is more than 1 device on each side for same caller(AoR?) (Jonathan). - Need to find out if it's suppose to work with IM, video etc? (Paul) - As I understand, need for new event pkg is pretty much what's on the table.(Keith) - Idea on the table is to have 2 servers and each monitoring the user with dialog pkg.(Miguel) - 5 Question mark on the spicy scale. Unsure what needs to be done.(Dean) ************************** 4. Next Step ------------------------- - Thinking the requirement draft will eventually be done we will need to respond.(Dean) - Do we need a draft that answers with an analysis of the requirements?(Dean - Do we want to set up the tracker like we do with 3GPP, with issues, dependencies and status.(Jon) - 3GPP had more detailed feature they wanted. TISPAN is asking with more overall architecture requirement.(Dean) - May be itfs better to have a liaison telling them about the existence of tracker and mentioning of items that are looked over.(Dean) - 3GPP dependencies tracker did not get stable until they acknowledge that they have dependencies and formal agreement was formed.(?) - With ETSI, TISPAN needs to be in agreement that they agree their dependencies on the specifications IETF presents. - Tracker and Liaison is complimentary.(Miguel) - Suggested way forward > proposal 1 Have ETSI contributor polish the requirement IETF develops the Response draft. > proposal 2 IETF keeps on providing the feedback so ETSI can work on analysis draft. - Jon explained the interaction between 3GPP and IETF. - This has been very reactive process.(Rohan) - Be proactive with recommending ways to accomplish things would be nice. (Rohan) - We need a victim to write the draft.(Cullen) - We need to have somebody that will write something here.(Cullen) - I donft see why draft needs to be written. Statement proposing the status and recommendation, I think is sufficient.(Martin) - Because thatfs how IETF works.(Dean) - I would volunteer to write the communicate(Erick) - I would be happy to write a communicate and having the tracker would be great.(Erick) - A quick communicate would be sufficient.(Dean) - Described Data tracker.() - Martin and Erick will write a communicate in the form of Draft.(Erick) ************************** 5. Miguel's presentation ------------------------- - Miguel explained a new requirement. - Ouch.(Dean) **************************