Dispatch IETF80 ================ Wed 15:10 Prague Chaired by: Cullen Jennings and Mary Barnes Notetakers: Peter Musgrave and Brian Rosen Jabber Scribe: Dan Burnet Conclusions: 1) Reason Header in Responses: We will proceed with this work - an Update to RFC 3326. Exact disposition TBD (i.e., AD sponsored or SIPCORE). 2) Q4S: Not enough WG interest in work to proceed with it. Links to audio files at: http://www.softarmor.com/dispatch/IETF80/agenda.mp3 http://www.softarmor.com/dispatch/IETF80/q4s.mp3 http://www.softarmor.com/dispatch/IETF80/reason-responses.mp3 ====================================================================================== Raw Notes Set One Agenda slides and brief mention of IMTC, UCIF and SIP Forum. Reason Header in Responses (Roland) How many people have erased the doc? [A fair number] Query the room: Should we do an update to 3326. [Partha] Agree problem solved, but there is no exact translation from Q.850 response code to SIP Why is there a requirement for a response code? Why do this in IETF now? Requirement for SS7-> SIP came after RFC3326. [Mary] We are not standardizing this [Martin Dolly] Previous mappings done in IETF were wrong. In SIP-I still ended up with many to one or one to many mapping which caused interop issues. Adding 850 code makes this unambiguous, helps interop. [Cullen (as Ind.)] Today multiple Q.850 -> one SIP response code. Three classes of solutions have been proposed: 1) SIP-T class 2) Extend SIP error codes to complete mapping uniquely (a few 500 codes) 3) This draft. Add a sub-field for Q.850 stuff [Mary] This is not exactly what is documented here. [Cullen] All 3 solutions work. Can we have a discussion of why this solution compared to others. [Roland] This was done before in the past [Keith] Doing this does not prevent e.g. 5xx codes. [Hadriel] I though mailing said we did not want to create more response codes. Elements will look at this reason header and act differently. This works. I see nothing which breaks. [Cullen] Want to understand why this one of the three. Agree this will work. [Partha] Mapping does not work - please document why not specifically. [Dale] Adding new response codes is difficult for backwards compatibility. Response codes will not scale if there becomes another class which want to convey response codes. So response codes not great. Can we take a hum to decide? [MartinD] For (1) this forces a node to force a binary ISUP compiler, so is not simple enough. (3) is only choice [Andrew] Agree new status codes are bad. In terms of getting things done, lets just go forward. [?] Can we describe which codes need to go through? [Mary] Mailing list discussion was clear we wanted to go with this approach. [Daryl] This is not solved in ISUP either, they will overload stuff there too. There is no end-to-end 1-1 mapping. The Reason header will not always tell you the details since ISUP can be altered too. I don't think we should do this work. [Hadriel] We need these codes, SIP devices will change behavior based on them. This is a good thing. [Cullen] Completely agree but come to opposite conclusion. In a mixed network prefer a more generic solution. We never have a face-to-face discussion about pros and cons of 1-3. Hum: Who would like to progress this work? Chair: Call that consensus in favor. Chair: Is this sipcore. (We'll take offline) Q4S (Jose) aka Q-HTTP [Peter] Why is this is RAI [?] Is there an architecture and requirements doc. no. Who has read the doc? (15 people) Who can contribute? (about 5) Who would implement and consider deploying? (4 people - 1 not an author) [Dean Willis] Would do well to do a prior art search, may be a lot of prior art IPR in this space. [Michel] Ma want to get into transport layer stuff. Raw Notes Set Two IETF 80 dispatch WG meeting Wednesday RSparks: SIPit registration closes this Friday, event in two weeks in Huntsville, AL US Roland Jesske presents reason responses Describes how Response carries Q.850 Codes List discussion resulted in conclusion to update 3326 to address a gap. Subsequent comments resulted in an -01. Chairs: How many have read the doc? Many Partha: Agree problem will be solved by the draft, but need two response code: SIP response code + Q.850 code Roland: Requirement arrived from ITU and within IMS Partha: But why now? Chairs: no MDolly: IETF mappings are wrong. Many to 1 mappings resulted. Need the actual code to get interop CJennings: Current mapping 1 to many, known for a long time. 3 classes of solns proposed: Take the whole message and transport it (like SIP-T), extend SIP error codes to have enough to map 1:1, Add a subfield. People have asked for comparison for why one is best. No discussion of 3 plans, why this is the right one. Roland: Put messages on list explaining why, got no opposing notes CJennings: So, no more error codes don't work Drage: Can still do that, and useful for good rendering at UA. Roland wants the semantics of the 850 cause code somewhere else in the network Kaplan: Agree with Cullen, believe we didn't want to create more error codes. UAs will act differently when they see these codes. That is fine. Jennings: No, this works. Don't recall any discussion of why this one is best. Don't recall discussion on more error codes Partha: better Worly: adding new response code is difficult because UAs don't behave well on codes they don't understand. Prefers subfield is better. Dolly: Been discussed many times over the years. Agree we could add status codes, consensus has been to not do that, and would never get 1:1 mapping. Encapsulation would force ISUP binary decoder to get the code. Allen: Concern with too many codes. Proposal on the table, just get it done. Sohel: Could we have more info in the draft on 850 codes Chairs: not the purpose of the draft - draft modifies 3326 to add response codes Kaplan: Doc should explain what code needed to be passed in the update Chairs: List discussion indicates no interest in doing this Malis: ITU overloads cause code values. We overloaded them in SIP, will never get 1:1. Getting the cause code won't actually tell you, because ISUP doesn't do it (configuration of switch can change codes). Don't think we should do this work. Kaplan: Of course switches can map codes. This is solving the problem of getting the codes back through SIP. We need the codes to do the right thing. Might even generate them, without changing SIP Jennings: Agree with Hadriel and comes to the opposite solution. Things other than 850 generate codes. Systems that only deal with 850 codes can do things fine. Other things generate codes and may need to be sent. The problem is we did not have a discussion of pros and cons of the 3 solutions. Chairs: Let's take a hum Who would like the update to 3326: lots Who doesn't want it: few Chairs: Where should we do this? Ganzalo: We can discuss how off line Javier Q4S Quality of user experience, both application and network based JPolk: RSVP scales Javier: Need dynamic updates JPolk: it does it ????: This is application level stuff. You can use RSVP if you want to use it and it works for you Musgrave: Proposed charter says "out of band application level protocol". Chairs: This has been discussed, and dispatch was the closest fit Jennings: is is real time QoS stuff, and RAI is it. ???: Where can I find the architecture and problem statement Chairs: charter proposal is it ???: Understand the solution, doesn't understand the architecture Kaplan: We could spend a long time on this. What are you looking for today? Chairs: Get feedback. What would we do with this now? Chairs: Who has read it? 15 or so Chairs: Who will do work? 5 Chairs: Who would implement and consider deployment in a real network? the 3 authors + 1 Willis: Prior art search may be needed. Believe a lot of patents on this.