Minutes for STOX at interim-2013-stox-1
minutes-interim-2013-stox-1-1

STOX Virtual Interim 2013-12-17

---

Chairs: Markus Isomäki, Yana Stamcheva

Participants at start: Emil Ivov, Yana Stamcheva, Markus Isomäki, Dave Crocker,
Mary Barnes, Paul Kyzicat, Peter Saint-Andre, Saul Ibarra Coretge, Jonathan
Lennox, Philipp Hancke

---

Collection of Action Points:

Mary Barnes: Review -im and -chat documents. (Note: Already done.)
Jonathan Lennox: Review the fmtp related section in -media.
Paul Kyzivat: Review the "hold" related section in -media.

---

Minutes by Emil Ivov:

Markus: discussion is to be mainly on media. Objections?
None
Peter: Thanks to Dave and those who reviewed!

Markus: quick status update:
        core and presence are in IETF last call. got some very nice reviews.
        updates have been made
Peter: a few more updates are pending based on deployment experience but mainly
editorial. Markus: time frame? Peter: this week

Markus: we also have im and chat. would be nice to have a few more reviews
Mary: I’ll look at those *** ACTION POINT ***
Markus: This week?
Mary: Possibly. Early next week in the latest
Saul: I also have some notes to send.

Markus: group-chat. we’ve had a few discussions. an update is pending
Saul: I actually did update
Markus: we’ll last call in January

Markus: today we’ll talk about media
Saul (presenting): we agreed last time that we will only do phone calls
(audio/video) and basic 3264
        advanced use cases are out of scope (e.g. 3pcc, call transfer, etc. )
Peter: dave’s comment is. we are providing guidance based on implementation.
where we don’t have that experience, we are not going to provide information
Markus: i am a bit confused. you say it’s only 3264 and then you talk about
ICE. which one is it? both? Saul: Yes, Jingle uses 3264 to refer to both
3264+ICE Emil: Yes it’s both

Markus: Second comment: would be good to state in the beginning to list what
features are handled exactly so that you don’t have to read the whole document
to know what’s possible and what isn’t. Peter: Good point Markus: Question for
the XMPP side. Emil: jingle clients check whatever’s supported between raw-udp
and ice-udp. so the gateway checks and decides what it wants to advertise. we
can advise on the risk Jonathan: do you fallback in jingle from ICE to raw-udp
as you do with SIP? Emil: no you don’t. it’s either or Peter: when we defined
it was with the premise that everyone would do ICE.

Saul: moving on. when not doing any trickle while the gateway said 3264, the
gateway would ignore trickled candidates (rather than barf)
        jingle and sip handle format parameters differently. jingle parses them
        while sdp handles them as opaque strings. gateways should therefore try
        to handle whatever params they understand and follow a set of basic
        rules when they don’t

Jonathan: given we care about compatibility with existing deployments can we
say that the formats that don’t use commas (except for speed) don’t really
exist with jingle? Emil: agreed. and we could add a specific example for speex.

Markus: jonathan can you review and send a suggestion (*** ACTION POINT *** )
Jonathan: OK

Saul: we also tried to address holds.
Emil: we advise not to try to translate sdp direction into hold commands
Saul: double hold could still be worth mentioning explicitly

Markus: Paul, could you also have a look at the hold stuff? (*** ACTION POINT
*** ) Paul: OK

Saul: we added text about trickle ICE saying we don’t handle
Saul: we say we don’t handle forking. when it occurs we forward ringing
responses and such as coming from the bare jid

Markus: you seem to be talking about jingle to sip here . is there an issue in
sip to jingle? Emil & Jonathan: Not really

Saul: looping. do we have a problem
Emil: 2 gateways could lead to a loop across the two sides
Jonathan: is this specific to jingle?
Peter: some of it applies to XMPP
Emil: forwarding messages is rare. forwarding calls is common

Emil: we can mandate that call id and sid match
Jonathan: that would break with b2bua-s … but we could still do it as a best
effort Saul: we should also pay attention to the destination so that we don’t
have false positives

Saul: do we handle empty invites?
Jonathan: you have to at least know what error to return.
Paul: it’s a valid use case so you need a story
… back and forth …
Saul: you can return an error or handle it entirely as an SBC. That OK?
Emil, Peter: yes, yes

Saul: we should say t.140 and t.38 are out of scope (but still mention that)
Paul, Jonathan, Peter, Emil: Agreed

Jonathan: are we going to fix the jingle issue that requires that ICE
foundations be integers Peter: recognized as a bug.

Jonathan: phone numbers?
Peter: component and discovery

Markus: out of scope