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