SIP-to-XMPP (STOX) WG meeting minutes, IETF 87, Berlin, August 1, 2013 Contents: 1.) Chair summary by Markus Isomäki 2.) Minutes by Jean Mahoney 3.) Notes by Jean Mahoney 4.) Notes by Philipp Hancke --- 1.) Chair summary by Markus Isomäki * Charter Principles: At the moment consider only features that are mature in both SIP and XMPP. Mature means the IETF and/or XSF standards are completed, and there are known and deployed implementations. Q: Is file transfer on the charter? A: Not at this point. The XMPP/XSF file transfer spec(s) do not currently meet the matureness criteria. Once they stabilize, SIP mapping can be considered. * Core - Issue: Should something general about forking be defined here or is it purely a -media issue? - Issue: Add text about Max-Forwards and Max-Breath. Loop detection in general. * IM - Issue: Contact header is not allowed in SIP MESSAGE, need to fix the draft. * Presence - Issue: Mapping between XMPP's permanent and SIP's soft-state (refreshed) subscriptions. * Chat - Issue: Mapping between XMPP ChatStates (XEP-0085) and isComposing event (RFC 3994). - Issue: Mapping between message receipts (XEP-0184) and MSRP REPORT chunks (RFC 4975). - Consider if the above two are included or possibly split into a forthcoming advanced-chat draft. - Issue: Draft says gateway determines MSRP is supported before sending INVITE. How? * Groupchat - Issue: Need to define what to do in case of multiple clients. Use and mapping of JID, AoR, contact. * Media - Issue: "Hold" needs to be more carefully defined. What does it actually mean on both sides and how are those meanings mapped. a= does not always mean "Hold". - Issue: Forking needs to be explained either in -media or -core. - Issue: a=fmtp mapping. * Next steps - Reviews for -core and -presence first by August 16 - Reviews for -im and -chat by August 30 - -groupchat and -media will need further revisions --- 2.) Minutess by Jean Mahoney SIP-TO-XMPP (STOX) WG AGENDA THURSDAY, August 01, 2013 (Charlottenburg 1), 17:00-18:30 (90 mins) IETF-87, Berlin, Germany Chairs: Markus Isomaki (markus.isomaki@nokia.com) Yana Stamcheva (yana@jitsi.org) ---------------------------------------------------------------------- 17:00-17:10 (Chairs, 10 mins) Introduction and Status Update, Forthcoming milestones presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-0.pdf Markus Isomaki presented. Note takers: Jean Mahoney, Philip Jabber scribe: Olle Johansson Jabber log: http://www.ietf.org/jabber/logs/stox/2013-08-01.html Paul Kyzivat mentioned that he didn't see file transfer covered and Saúl Ibarra Corretgé suggested rechartering to add file transfer. Joe Hildebrand said that jingle transfer should be covered first, but Peter Saint-Andre said that it would be a little while before it's stable. ---------------------------------------------------------------------- 17:10-17:20 (Peter Saint-Andre, 10 mins) draft-ietf-stox-core-00 draft-ietf-stox-presence-00 draft-ietf-stox-im-00 draft-ietf-stox-chat-00 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions, Presence, Instant Messaging and One-to-One Text Chat Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-1.pdf Peter Saint-Andre presented. slide 7 - Chat Joe Hildebrand and Saúl suggested doing the entire mapping for XEP-0085. Jonathan Lennox wondered if it was worth splitting core chat and chat extensions and dealing with core first. ACTION - Peter to discuss chat state mapping issues and look at how much work is there. There was a discussion of the use of MSRP reports. If they are not widely implemented, work on them could be done in the future. Peter requested that Christer write up his review and send it to the list. ACTION: Christer Holmberg, Ben Campbell, Mary Barnes, Dan to review the chat draft and send to the list. There was a discussion about how subscription requests should be handled at the gateway, or at the XMPP client. ACTION: Peter to update the core and presence documents after the meeting. There was a discussion about the use of the Contact header field. ACTION: Peter to review RFC3428 for Contact header usage. ---------------------------------------------------------------------- 17:20-17:40 (Saúl Ibarra Corretgé, 20 mins) draft-ietf-stox-groupchat-00 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-2.pdf Saúl presented. slide 4 - Open Issues No one in the room objected to the handling of nicknames. As for the handling of IDs, there was confusion on which type of chat room was being discussed. The issue of a SIP AoR with multiple contacts was raised. ACTION: Saúl to write up the issue of JIDs, multiple clients and chat rooms. ---------------------------------------------------------------------- 17:40-18:10 (Saúl Ibarra Corretgé, Emil Ivov, 30 mins) draft-ietf-stox-media-00 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-2.pdf Saúl presented. There was a discussion about the mapping of hold, which isn't in SIP, and the handling of forking, Max-Forwards and Max-Breadth, which aren't in XMPP. ACTION: The authors to start threads on mapping hold, handling forking, and handling Max-Forwards/Max-Breadth. ACTION: Add text to the core draft to cover Max-Forwards and Max-Breadth. ---------------------------------------------------------------------- 18:10-18:30 (Chairs, 20 mins) Summary and Next Steps Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-3.pdf --- 3.) Notes by Jean Mahoney SIP-TO-XMPP (STOX) WG AGENDA THURSDAY, August 01, 2013 (Charlottenburg 1), 17:00-18:30 (90 mins) IETF-87, Berlin, Germany Chairs: Markus Isomaki (markus.isomaki@nokia.com) Yana Stamcheva (yana@jitsi.org) ---------------------------------------------------------------------- 17:00-17:10 (Chairs, 10 mins) Introduction and Status Update, Forthcoming milestones presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-0.pdf Markus Isomaki presented. Note takers: Jean Mahoney, Philip Jabber scribe: Olle Johansson Jabber log: http://www.ietf.org/jabber/logs/stox/2013-08-01.html slide 4 - Agenda Overview Markus - more time is given for the groupchat and media presentations. slide 5 - Status Update Markus - various drafts have been around since 2004. Make sure that there are no open issues. Working group should be done by next IETF meeting. slide 6 - Preliminary Timeline on Draft Review Deadlines Markus - Based on today's meeting, see how the WGLC will be arranged. They aren't arranged yet. slide 7 - Forthcoming Milestones Markus - The presence, im, and chat drafts are more stable. slide 8 - Principles Markus - We will only include features that are stable - not taking on works in progress. Features that have some amount of real implementation. Leave the door open for new functionality introduced through separate extension docs. Emil Ivov - you can go further - not going to map anything past RFCs 3261, 3264. Markus - Let's leave that discussion to the media signaling discussion Paul Kyzivat - what about file transfer? I don't see it here. Saúl Ibarra Corretgé - Recharter to add file transfer. Joe Hildebrand - There are multiple ways of doing file transfer - 16 combos. Doing jingle transfer first would be a good thing. How close are we? Peter Saint-Andre - It will be a little while before it's stable. Could do service discovery - a whole suite of things to discuss but not solid enough. These are the core things that work well. Markus - Get these docs published, but it doesn't preclude taking new things on. ---------------------------------------------------------------------- 17:10-17:20 (Peter Saint-Andre, 10 mins) draft-ietf-stox-core-00 draft-ietf-stox-presence-00 draft-ietf-stox-im-00 draft-ietf-stox-chat-00 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions, Presence, Instant Messaging and One-to-One Text Chat Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-1.pdf Peter Saint-Andre presented. slide 3 - Core (1) Peter - Robert's proposal wasn't sent to the list. It seems like the correct approach. Any objections? No objections from the room. slide 4 - Core (2) Peter - Only jabber.org supports _im and _pres. slide 5 - Core (3) Peter - these don't completely line up but are close enough. According to RFC6120 the element isn't supposed to be shown to the user, it's used for testing. RFC3261 could use a bis effort. The proposal is mostly reasonable, and I'll add text. slide 6 - Presence Peter - There is no universal handling of core states - I'm away, DND. Implementers have put in custom namespaces. Will go with the proposal here. slide 7 - Chat Peter - Will raise this issue on the list, too. Bullet 1 hasn't been included in the draft yet. I hesitate to add because I don't want to add scope. Christer Holmberg - it's a bis draft. Joe Hildebrand - if you do it, do the entire mapping for XEP-0085. Saúl - I propose this, all the states in 3994 map to XEP but not the other way around. Jonathan Lennox - is it worth splitting core chat and chat extensions and dealing with core first? Peter - maybe. ACTION - Peter to discuss chat state mapping issues on the mailing list and look at how much work is there. Peter - Mapping between message receipts. Do MSRP implementations do the chunk reports? Saúl - MSRP reports are with chat and everything - success reports. I have concerns as well - In XEP, if an entity requests receipts but the other end may chose not to send. Mapping - always send them. Ack a problem. If the receipt doesn't come, you do something. Peter - is this useful between a gateway and SIP UA even if it doesn't get to the end? Saúl - this report is the second tick in what's up. We rather some indication in our implementation. […] Or you mirror the receipt. I'm ok with another document. They map well conceptually. Peter - we could do a survey of the MSRP receipts. If not widely implemented, we could add it in the future. Saúl - I saw it in gmail.com - that's a big service. Peter - I'm more interested in the breadth of coverage - lots of implmentations. It's true of chat state notifications, not sure about message receipts. Christer - Question on scope - the draft says the gateway will determine if MSRP is supported on the side. It should be out of scope. Peter - it would be great if you write up the review. Ben Campbell - I will review the chat draft. On the presence mapping draft - the concepts of subscription in SIP and in XMPP are different. An XMPP subscription is forever until you turn it off. GW will have to refresh subs forever. On the other side, the users are being re-asked. Do we have the right mapping? ACTION: Ben Campbell to review the chat draft. Emil - It would be good to clear it up. It needs to be ironed out. Joe - We solved this by no-opping the presence request in code. It is not efficient. Ben - The gateway has to be smarter. Going to be dealing with clients that aren't aware of the gateway. peter - 2 choices - Have an XMPP user popup, which violates least user surprise, or have the code eat it. Peter - Back to the review deadline slide - I will attempt to update the core and presence docs by sunday. Then I'll do the IM chat ones. Markus - how many have read the draft - 10 people. How many will review? Dan, Ben …. Mary. about half a dozen. Christer - on the im draft - It may be an copy/paste error - in the draft in the SIP message, you are using the Contact header, which is forbidden. Is there is a usage? Then we may have a problem. Saúl - It can be an issue, the Contact header may have a gruu, if we translate in XMPP. We may have a problem. Only for normal and inline messages, not for chat. Christer - we've discussed in 3GPP. If you have that use case, you have to make that happen. Other SDOs would be interested. Markus - not in the charter on the SIP header. Can't assume anything about it. SHouldn't use it. If you have a proposal, please make it. Keith - It doesn't work, it's not allowed. If you make it work, you turn the message into a dialog and you should use XMPP. Peter - I'll check RFC 3428. ACTION: Peter to review RFC3428 for Contact header usage. ---------------------------------------------------------------------- 17:20-17:40 (Saúl Ibarra Corretgé, 20 mins) draft-ietf-stox-groupchat-00 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-2.pdf Saúl presented. slide 4 - Open Issues Saúl - I've spotted editorial issues. Handling nicknames. In SIP, the payload for conference info 4575 - field Display-Text - is supposed to be there. draft-simple-chat added an extra field. There can be collision. This draft that we look in Display-Text. Put nickname set in MSRP. Any objections? None. Saúl - user ID on the SIP side, on the XMPP side we have 2 ids - occupant JID, and your real JID. How do we put those together without disclosing info? real JID as the user. Chatrooms created with this specification would not be anonymous. You need the real JID. Olle - there are 2 cases - jabber and SIP clients in a MUC. And a chat room - the SIP client won't reuse ID. Saúl - we talking about […]. Mary Barnes - My concern is that a user can have multiple end points. If you map, will it work? one user-one end point? Saúl - join with three clients with three nicknames. Joe - 3 JIDS Mary - that's inconsistent with 4575 Saúl - each of the end points is the occupant JID Peter - I think we want to look at […] Admins can see jabber ID, but other users can't. Do similar concepts apply on the MSRP side? Saúl - there's not way to specify local policy. Publish [...] Joe - it's important that you don't leak their real JIDs. Olle - we need to separate on chat rooms. You are talking about jabber chat, and you are talking about MSRP room. We need to separate them. Saúl - you will need to build the same document regardless. If you start from the SIP side, it can't be anonymous […]. Paul - Multiple clients - in the SIP world, you have one AoR and multiple contacts. Saúl the user has […] endpoints. paul - XMPP user with XMPP Saúl - one AoR and occupant JID Joe - each endpoint - contact - has to have a separate group in the room. Markus - people are confused. You would write up the issue on the mailing list to discuss. ACTION: Saúl to write up the issue of JIDs, multiple clients and chat rooms. ---------------------------------------------------------------------- 17:40-18:10 (Saúl Ibarra Corretgé, Emil Ivov, 30 mins) draft-ietf-stox-media-00 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-2.pdf Saúl presented. slide 5 - Media Markus - Who has read the draft? About 3 people raised their hands. slide 7 - The Plan Saúl - SDP doesn't work the same as jingle. First define SIP XMPP to […] jingle. Then work on syntax. transfer - signaling only - do in different document. slide 8 - Open Issues Saúl - proposal - call starts the SDP direction, use that - from then, we rely on session-info and the gateway to keep state. Christer - adding an issue - you need a story on forking - XMPP to SIP and the INVITE gets forked. It should be covered. ACTION: Emil - B2BUA - tell XMPP to SIP gateways to be B2BUAs. Forking can happen. About the hold - from the XMPP to SIP, you have to handle hold. The hold element would have to handle that. From the other way around, have to use hold as well. Saúl - what if I want to start a call with the direction of receive only? We always reply with session information. Emil - have to kinda guess. When you know it's a hold, use hold in XMPP. Saúl - from XMPP end point, have […] direction. The jingle endpoints use hold. Paul - I know too little on XMPP. SIP doesn't signal hold. Can't assume that you got a send, only that you got hold. Emil - a SIP endpoint would use it to show you've been put on hold. An XMPP gateway could do the same - guessing. Olle - Is there is any risk that it will create a loop and look at max forwards and max breadth? Loop detection and max breath explosion is very important. I din't see them in the docs. Saúl - like a B2BUA sending the call back. Do you want to see some text? The room said yes. Markus - where should it go? The room muttered core. ACTION: add text to the core draft to cover Max-Forwards and Max-Breadth. Keith - need to be careful of what hold means. PSTN, ISDN, SIP - only interrupts the media resources. What does it mean in jingle? Saúl - More oriented to call. If you want to set your direction to send only […]. The jingle endpoint would know you aren't going to send anything. Emil - hold - reading from XEP 167 Jingle. Paul - Does XMPP have anything like Max-Forwards? Saúl - don't know. Peter - no. We don't forward. Paul - Max-Forwards would be preserved in the best case. Saúl - […] if the endpoint does B2BUA, […] Paul - If I hooked up a SIP-based recorder to a server that was connected into XMPP. Receive only and never sends anything. It's not a holdee. Saúl - you have that problem in SIP. Paul - receive only doesn't mean hold. Saúl - how else to do it? Olle - The hold in XMPP is like stop media. RTCP […] Emil - RTCP keeps going. Paul - do you have the concept of inactive - that's mutual hold. A SIP endpoint just puts […] Hadriel Kaplan - we see send only all the time - it's not hold. Saúl - In jingle hold means hold, in SIP it means something else. What do we do? How do you translate the […] Hadriel - […]. Lennox - you receive a send only Hadriel - […] Saúl - […] Peter - the jingle specs aren't very sophisticated. They don't talk about RTCP. We'll have to look at it. I question that hold is something to talk about. Saúl - session info is used. How do you send […]. Peter - we need a mapping for the sender's attributes. This is a rathole and this should go to the list. ACTION - Discuss the mapping of hold on the list. Saúl - the way to signal call hold is to look at the sender, but jingle endpoints don't do that. So we need to set the initial direction. I need to rewrite the whole thing. Keith Drage - This problem has been seen with PSTN and ISDN, and they are widely deployed - check XMPP - SIP - PSTN, based on a flow in 3GPP TS [...]. Lennox - There is a meta issue about hold - in general jingle spec is vague. Need to figure out what they actually do. Saúl - these specs have working code. Lennox - interoperable code? Saúl - yes. Hadriel - back to the max forwards - […] Someday you'll let the second client. Peter - it doesn't exist right now. Hadriel - I suggest new feature - call forwarding and I suggest max-forwards Peter - client to server - server sends to another federated server to the client. Olle - you don't know. You can hit another gateway and that's where the problem is. Emil - a=fmtp - won't work unless the gateway understands. XMPP to SIP gateways will be a B2BUA. Saúl - there are some changes in the ICE syntax in XMPP and SIP. jingle - ICE foundation is a number in SIP. It's a string. Gateway will need to deal - put a number just in case. Emil - I'm not sure that's safe to do at the gateway. Lennox - forking? Saúl - jingle is unspecified. Emil - we're getting there. Lennox - design forking. Saúl - Today there is no such capability. Lennox - do you handle 183? Robert - philosophically gateways are modeled like B2BUAs. Markus - the authors will start a few threads - hold thread - forking - max forwards ACTION: The authors to start threads on hold, forking and max-forwards. Markus - no timeline for the media draft right now. Discuss the open issues. Will set the reviews for the other drafts. Discuss open issues on the list. Markus - reviewers please come up after the reviews. Anything else for this session? ---------------------------------------------------------------------- 18:10-18:30 (Chairs, 20 mins) Summary and Next Steps Presentation: http://www.ietf.org/proceedings/87/slides/slides-87-stox-3.pdf --- 4.) Notes by Philipp Hancke Chair slides presented by Markus Isomaki: Jonathan Lennox: is this working group last call @ preliminary timeline? Emil Ivov: further than principles slides, charter is nothing beyond RFC 3264 Paul Kyzivat: what about filetransfer? Saul Ibarra Corretge: basically finish current set of documents first, recharter for filetransfer later Joe Hildebrand: xmpp has multiple filetransfer ways, should first do jingle-ft Peter Saint-Andre: not ready yet core, presence, chat slides presented by Peter Saint-Andre chat slide (#7): bullet 1: Saul Ibarra Corretge (?): mismatch in model between XEP-0085 and rfc 3994 Joe Hildebrand: seems like a reasonable thing, do complete XEP-0085 mapping Saul Ibarra Corretge: basically all states RFC 3994 map to XEP-0085 state but not other way round. Indication for "no further communication" Jonathan Lennox: recommends splitting core chat and chat extensions if this is bigger than expected Peter Saint-Andre: possibly bullet 2: Peter Saint-Andre: MSRP report chunks vs XEP 0184 Saul Ibarra Corretge: success and failure reports used by our implementation. text along the lines: you always offer receipts and ... you can map them to reports Peter Saint-Andre: useful between gateway and sip ua? Saul Ibarra Corretge: usually, msrp report is second pick. ok to defer to another document but do map well conceptually Peter Saint-Andre: not clutter up specs Saul Ibarra Corretge: saw it in gmail.com, big service, maybe not for longer. Peter Saint-Andre: breadth of coverage (different implementations) for chat states, not so much for 0184 receipts Christer Holmberg: draft says before invite is sent gateway determines whether msrp supported. by what mechanism? Peter Saint-Andre: send comment to the list please. presence slide (#6): Ben Campbell: mapping of subscription 1-1, xmpp permanent subscription, sip not permanent; refresh sip subscriptions go away all the time, reasked authorization; no answer Emil Ivov: see this problems often, needs to be handled Joe Hildebrand: solved that by no-opping some subscription request stuff. not efficient, but ... Ben Campbell: maybe gateway has to be smarter about lifetime of subscriptions Peter Saint-Andre: some text in mapping, please review, will update specs before sunday. chair question: how many people in the room read core/presence? around 10 read core/presence , half a dozen people offer review until august 16 roughly same people for im/chat chairs will send reminders, remember who offered Christer Holmberg: @im draft, using sip message contact header; explicitly forbidden; hopefully c&p error; Saul Ibarra Corretge: it can be an issue. contact may contain gruu; translate to jid; im-spec only specified for normal/headline Christer Holmberg: similar discussion in 3gpp, requirement to have multiple messages between same entities Markus Isomaki: not in charter of this wg; not use contact Keith Drage: not allowed. use msrp instead. do not break the rules Peter Saint-Andre: general goal is not making changes to sip or xmpp semantics. just explaining how it works over here and there 17:36 groupchat & media slides by Saul Ibarra Corretge groupchat: open issues slides: not many read draft, no strong objections at issue 1 Olle Johansson: two cases, one case where chatroom is muc, sip client going into that; other is sip msrp room, jabber client joining. Saul Ibarra Corretge: case 2 is meant at issue 2 Mary Barnes: concern user can have multiple endpoints. Joe Hildbrand: three full different jids when joining with three clients Mary Barnes: slightly inconsistent with (number of msrp chat rfc) Peter Saint-Andre: different kinds of rooms in xmpp, different visibility of jid. does that apply to msrp too? Saul Ibarra Corretge: respect policy, only publish occupants jids Joe Hildebrand: important not to leak real jids for (semi?) anonymous rooms Olle Johansson: confused about which case we're talking about Saul Ibarra Corretge: same document regardless. Paul Kyzivat: more about marys question, multiple clients. in sip there is one aor, multiple contacts. conf needs to see aor. map xmpp user to three aor? Saul Ibarra Corretge: one aor Joe Hildebrand: important thing to keep in mind: each endpoint has to have different nickname Markus Isomaki: please discuss on mailing list how many people read groupchat? less than 3 media: settled for existing standards; nothing new plan: reorg structure call model vs sdp mapping Christer Holmberg: story on forking on the sip side needed Emil Ivov: @christer: be a b2b ua Christer Holmberg: forking can happen, do something proposed hold plan: callstart, use content senders; then use session-info; gateways need to be stateful Emil Ivov: hold, xmpp2sip must be handled; sip2xmpp should use hold, but may use content senders Saul Ibarra Corretge: start a call with a=recvonly? Emil Ivov: easy to distinguish. Saul Ibarra Corretge: need direction attribute on first sdp. jingle clients typically use session info Paul Kyzivat: different notion of "call". no hold in sip. a= can not be assumed to map to hold. Emil Ivov: guesswork Keith Drage: careful with hold as to what it actually means. PSTN: "release the resources". ISDN: "release media resources, keep signalling resources". SIP: "interrupts media resources". Saul Ibarra Corretge: [...] Emil Ivov: xep-0167 has straightforward definition of hold. Paul Kyzivat: sip based recorder, recvonly; not a holdee; Olle Johansson: hold in xmpp is like the old hold sip media ip 0.0.0.0 ip; continue rtcp. what does jingle do? Emil Ivov: rtcp keeps going Saul Ibarra Corretge: jingle sometimes is a bit loose Paul Kyzivat: do you have an ack? Emil Ivov: [...] Hadriel Kaplan: see sendonly all time, not for hold Saul Ibarra Corretge: in jingle hold means hold. in sip may mean something else Saul Ibarra Corretge: translate sendonly to hold Peter Saint-Andre: jingle spec not sophisticated. dont talk about rtcp at all. unspecified. look at how people implement. do we even use hold? Saul Ibarra Corretge: all implementations use hold. call typically sendrecv, Peter Saint-Andre: need spec on senders attribute; Keith Drage: other people also hit problem. fairly widely deployed assumptions... xmpp -> sip -> pstn go along with those Jonathan Lennox: jingle pretty vague; figure out what interoperable implementations do; do what sip does otherwise Olle Johansson: is there any risk from sip2xmpp creating loops? 17:11 < xmpp:stox@jabber.ietf.org/oej%20(scribe)> I don't find max-forwards and max-breadth in the documents. We do need loop and explosion control. some text please. Markus Isomaki: to which document, probably -core Paul Kyzivat: does xmpp have max-forwards? Peter Saint-Andre: we don't forward things Paul Kyzivat: preserve max-forwards Saul Ibarra Corretge: doesn't exist... Olle Johansson: remember the "x" Hadriel Kaplan: max-forwards: xmpp does forward in a sense. Peter Saint-Andre: come join us xmpp guys! no forwarding in this sense; architectural assumptions Olle Johansson: can happen, jabber endpoint asterisk. still have forwarding problem when sip->xmpp->xmpp client->gateway Emil Ivov: a=fmtp only if gateway understands format; gateways are b2buas Saul Ibarra Corretge: slight differences for ice cands; foundation probably Emil Ivov: not sure if safe to replace foundation; Jonathan Lennox: if i said forking, how fast would i have to run Emil Ivov: use message instead of iq for forking Jonathan Lennox: design it unlike sip fork on sip side? Saul Ibarra Corretge: gateway has to show a single call Jonathan: what is handled? 100, 200? (????) Robert Sparks: previous versions (reviewed long ago?) of drafts basically assumed b2bua Markus Isomaki: start threads on list: hold forking max forwards a=fmtp Markus Isomaki: groupchat and media no timeline. Saul Ibarra Corretge: groupchat some issues; media rathole discuss on list