1.1 SIP-XMPP DISPATCH ad hoc
1.1.1 Agenda Bash
Jon - have about five slides on voice-presence interaction if there's time.
Robert - concerned about people in the room ("where are the XMPP people?").
1.1.2 SIP-XMPP Combined Use Motivation and Use Cases
SIP is dominant for telephony and XMPP is dominant for Presence-IM. Many people have separate accounts for each. Want to combine the separate accounts in a single client (that works coherently) - the proposal on the table is NOT interworking between SIP and XMPP.
Combined client may support different use cases during communication and not-during communication - both are useful.
Adam - requirements has more solution text than is actually needed. Doing this with no server support at all is a requirement - should be included. Need to do a little more analysis to tease out the requirements from the solutions.
Robert - need to make interworking between a SIP-only endpoint and an XMPP-only endpoint explicitly out of scope.
Adam - understand "no server modifications required" but there are server modifications that might make things work better - that should be allowed.
Adam - if it can be changed, there's a B2BUA out there that will change it.
Will we address the non-communicating use cases in the proposed work? That's the proposal.
1.1.3 Technical Overview of SIP-XMPP co-existence
Goal is to make the user think that we're using one protocol, even though we're using two protocols. Some challenges doing this.
Needed "glue" - learning the address in one protocol using the other protocol, correlating two independent sessions into one conversation. Need to address overlapping features. Need to make sure we don't break anything that works today.
Jon - may be a variety of ways of doing this, don't know that we'll pick one or that we need to pick one.
John - hope that a lot of things will turn out not to be broken and we won't have to say much, and if things are broken we can push them to the side and not say much.
Adam - we're always going to want a JID resource or a GRUU, and JID resources in particular are pretty dynamic - not sure how we can publish these.
Cullen - how will correlated parts of a conversation be presented differently than two uncorrelated conversations?
Adam - want to be able to mute both, for examples. There are situations where it's useful to bind them together. Transfer both at the same time.
Adam - put these both in the SDP so they are part of the same session and then you can move them together naturally.
Have existing opaque identifiers in both protocols (Call-ID, <thread>) - use these, don't make new ones, and hope that they get through SBCs (evil laughs happen here).
Cullen - people theoretically put IP addresses in Call-IDs, that's why they twiddle with them.
Could use Session-ID that's been deployed.
Jon - this is an arms race, SBCs will always twiddle with everything they know about, use Call-ID and move on.
Adam - if you use SDP for this most of the problems just melt away.
Jon - chicken-and-egg - if you use XMPP presence to set up a SIP call that controls an XMPP session, how does that work? This isn't just getting XMPP's identifiers into SIP, it's also getting SIP identifiers into XMPP.
There's no such thing as an XMPP session - just a TCP connection. Presence isn't a thread.
Start with simple use cases and extend later.
Should the IETF be working in this area? Strong hums with no opposition.
Jon - document we have now is narrow in scope.
Gonzalo - question is whether you want to limit that in the charter. We can recharter at any point.
Proposed charter is a good place to start? Hums (less strong) with little opposition.
Who is interested in actively collaborating, writing drafts? 4-5 people in the room (and we're not using JabberL).
1.1.5 Presence-based session advertisements
Cullen and Jon as individuals.
Move to stronger statement about a common model.
Problems started with SDP...
Replace offer-answer with a different model - advertisement and proposal (so you have a single document that describes the session). SDP doesn't actually describe a session - you take the offer and answer, and put them together to describe a session.
Robert - looking forward to details. Smells like connectivity checks are entirely reactive?
Cullen and Jon put together a draft over lunch...
Do connectivity checks constantly with everyone on your buddy list? Yes, and we think that's a feature. Most of the devices Cullen sees do OPTIONS every 15 seconds as a Keepalive anyway - don't see these checks as a new issue.
Robert - not key. Could pass OPTIONS and figure out what to put in the INVITE. Security considerations might get the presence server more involved.
Connectivity checks aren't mandatory all the time, may not be involved at all. Same for keying for media-level security.
May have some opportunities to use the GROBJ discussed in another BoF this week.
Don't want combinatorial explosion - either device supports an approach or not. That's what killed SDP-NG.
Roni - but you might not be able to run all the codecs you support at once.
Yeah, advertising means advertising...
"Early media" isn't really a concept any more - you send a document that completely describes a session and if the other guy accepts it, you have a session.
John Elwell : so you'd need to support traditional SIP, right?
Cullen : thought about this and didn't see issues.
Adam : think you need per-peer visibility (for example, security wouldn't be the same for all peers) - can you do this with XMPP presence? Selectively lying?
Cullen : think you can do this.
Would love to hear from our ADs - where do we go from here?
Will have a real draft next IETF...