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

session.

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: Agree.

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.