SIP-XMPP Ad-Hoc Meeting
November 13th 14:00-15:00
- Chair: Simo, Gonzalo
- Note taker: Shida
## Use-cases/Requirements presented by Markus ##
Markus explained the motivation, assumed architecture, use-cases and requirements.
Adam/Roni: Expressed concerns about requirements being too specific
with the mechanism/technical approach.
Robert: Questioned whether XMPP and SIP endpoints talking to
each other will be in scope.
Markus: No. Only assume the integrated XMPP/SIP endpoint.
Emil: SIP/XMPP both have presence etc. need to have some BCP to clarify
how the UA should deal with overlapping information.
Markus: The assumption now is that there is no overlap in feature.
Adam: Expressed the concern with how may be device implement
both XMPP/SIMPLE presence and some conflict information among the two.
Emil: Expressed that he doesn't want to have conflicting information or
have some guidance on how to deal with conflicting information.
Adam: Agreed that requirements about not touching the server is good,
but there may be some optimization(configuration etc.) that
can make things work better.
Simo: Agrees that something needs to be said about the concern.
Especially about presence.
Markus: Important requirements are to not harm the current deployments.
Gonzalo: Make sure backward compatibilities are addressed.
Markus: B2BUA etc. needs to be considered as correlation information
may need to be used.
Adam: Nothing can be reliable with B2BUA.
Markus: Expressed that we can at least try by avoiding what
we know it(B2BUA) already changes.
Roni: Asked if off-line cases are considered?
Markus: Yes all of the use-cases are within scope.
## Technical Solutioin overview presented by Simo ##
7 people(Out of 20 or so) in the room have read the drat.
Simo explained the slide (Challenges)
- Need address used in the other protocol and way to correlate the
Hisham: Expressed that he doesn't think overlapping feature is a concern.
Roni: Asked if distributed device relevant or irrelevant?
Jon: Thinks meaningful. Should explain how to do this(distributed).
John: Agree about the concern about overlapping features, and
thinks it's good to do due-dilligent but
if something needs to be done, hope that it's not much that we have to do.
Simo further explained how addressing is done.
Adam: Expressed that AoR/JID exchanged statically will not work
because for it to work, address has to be GRUU or JID-resources.
Simo explained the correlation slide.
Adam: Explained that XMPP doesn't fork
like SIP, it just pings the one with highest priority.
Simo: Thinks the current spec addresses majority of the case
but that's really an assumption.
Cullen: Qestioned the purpose of correlation.
Adam: Explained that for UI and user's perspective it's important
to couple the two.
Cullen: Questioned what happens if there is a transfer?
Adam: Agreed that it will be a problem. Suggested that it should be done in SDP.
Simo: Questioned how far we need to go.
Simo further explained the correlation slide.
Simo: Explained the problem with call-id.
Adam: Expressed that it doesn't matter where you put the
correlation information. It will be removed by B2BUA(SBC).
Adam: Suggested that correlator be put in SDP.
Jon: agreed with Adam.
Simo explained the slide on technical issues.
Salvatore: Asked about the correlation between on-going XMPP work?
Markus: Talked to XMPP chairs, they are happy to take it on
but it's up to the AD.
Spencer: Asked why real-time text being out of scope.
Simo: Explained because there is no implementations.
Adam: Explained that if XMPP session is treated as a
media stream than no problem.
Jon: Argued that IM > SIP case needs to be considered.
Adam: Explained that it can be solved if talking about
the pre-existing XMPP session in SDP.
Jon: Expressed that he is really talking about XMPP
presence being the trigger to start SIP session.
-- Note taker is confused --
Simo proposed the way forward.
Robert: Re-confirmed whether the scope is about the integrated end point
and that it does this for the endpoint's benefit to correlated the two.
Robert: Asked if defining SIMPLE-XMPP GW etc. is out of scope.
Simo: Agreed about Robert's scoping question.
-- Gonzalo Taking hum --
Should the IETF work on the problem space?
- Full consensus
Should charter as proposed today acceptable?
Roni/Jon: Solution only for single endpoint?
Gonzalo: Thinks it's useful to just start working on the simplest case.
Question is whether to narrow the scope now.
Jon: Suggest to narrow the scope.
Jon: Scope it to focus so it enables this for composed endpoint.
Are people happy with the charter with text discussed being reflected?
- Strong consensus with little opposition.
Who is interested in collaborating with the WG(chair/write).
- About 5 people out of 20 or so.
Charter will be scoped/revised according to the debate and will be sent to
AD for further treatment.