Subject: [Stox] IETF 87 minutes

From: <[email-masked]>
Date: Wed, 14 Aug 2013 19:19:30 +0000

Hi all,

Please find attached the notes of the STOX session recorded by Jean Mahoney and Philipp Hancke. I have also collected the main issues raised and discussed below as a summary. Some of them have already been discussed on the list after the meeting. You can find more details about each within the minutes.

Please let the chairs know if you have any comments on these before we post them for the proceedings.

Regards,
	Markus

----

* Charter

Principles: At the moment consider only features that are mature in both SIP and XMPP. Mature means the IETF and/or XSF standards are completed, and there are known and deployed implementations.

Q: Is file transfer on the charter?
A: Not at this point. The XMPP/XSF file transfer spec(s) do not currently meet the matureness criteria. Once they stabilize, SIP mapping can be considered.

* Core

- Issue: Should something general about forking be defined here or is it purely a -media issue?
- Issue: Add text about Max-Forwards and Max-Breath. Loop detection in general. 

* IM

- Issue: Contact header is not allowed in SIP MESSAGE, need to fix the draft. 

* Presence

- Issue: Mapping between XMPP's permanent and SIP's soft-state (refreshed) subscriptions.

* Chat

- Issue: Mapping between XMPP ChatStates (XEP-0085) and isComposing event (RFC 3994).
- Issue: Mapping between message receipts (XEP-0184) and MSRP REPORT chunks (RFC 4975).
- Consider if the above two are included or possibly split into a forthcoming advanced-chat draft.
- Issue: Draft says gateway determines MSRP is supported before sending INVITE. How?

* Groupchat

- Issue: Need to define what to do in case of multiple clients. Use and mapping of JID, AoR, contact. 

* Media

- Issue: "Hold" needs to be more carefully defined. What does it actually mean on both sides and how are those meanings mapped. a=<direction> does not always mean "Hold". 
- Issue: Forking needs to be explained either in -media or -core.
- Issue: a=fmtp mapping.

* Next steps

- Reviews for -core and -presence first by August 16
- Reviews for -im and -chat by August 30
- -groupchat and -media will need further revisions

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Aug 2013 12:02:04 -0600

> - Issue: Should something general about forking be defined here or is it purely a -media issue?

I think this is best left for the stox-media spec.

> - Issue: Add text about Max-Forwards and Max-Breath. Loop detection in general. 

IMHO we could say something like the following in the stox-core spec...

   A gateway between SIP and XMPP (in either direction) effectively acts
   as a SIP proxy server.  Therefore the amplification vulnerability
   described in [RFC5393] can manifest itself, and a gateway SHOULD
   implement the loop-detection methods defined in that specification to
   help mitigate the possibility of amplification attacks.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Aug 2013 08:32:26 +0200

> I think this is best left for the stox-media spec.
Do remember to handle the case where one sip INVITE can get multiple 200 OK. It's a corner case, but it does happen.
And it's signalling.

>   as a SIP proxy server.  Therefore the amplification vulnerability
b2bua, not a proxy. There's a draft in the straw wg mandating b2bua's to support
max-forwards and max-breadth

>   help mitigate the possibility of amplification attacks.

Agree. How are these headers handled in XMPP?

/O

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Aug 2013 16:27:09 -0600

On 8/20/13 12:32 AM, Olle E. Johansson wrote:
> Do remember to handle the case where one sip INVITE can get multiple
> 200 OK. It's a corner case, but it does happen. And it's signalling.

That sounds like fun.

>> A gateway between SIP and XMPP (in either direction) effectively
>> acts as a SIP proxy server.  Therefore the amplification
>> vulnerability
> b2bua, not a proxy.

Correct. I'll fix that in the next version of stox-core (which now says
"proxy").

> There's a draft in the straw wg mandating b2bua's to support 

I assume that is:

https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection/

>> implement the loop-detection methods defined in that specification
>> to help mitigate the possibility of amplification attacks.
> 

We don't have those headers in XMPP because we think that we don't have
multiple hops to worry about.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 21 Aug 2013 00:41:20 +0200

>> 200 OK. It's a corner case, but it does happen. And it's signalling.
This should be caught by the gateway, handled locally, like any SIP 
endpoint UA (and how is happening for PSTN gateways). Only one 200ok 
should be propagated to xmpp/jingle side. Which one? A matter of the 
implementation, most I have seen they go with the first response 
received, for the others they send ACK followed quickly by BYE (I mean, 
the good SIP UA implementations, some just crash in such cases :-) ).
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Aug 2013 16:48:30 -0600

> - Consider if the above two are included or possibly split into a forthcoming advanced-chat draft.

The sense of the room that I perceived was to map the first but not the
second, since I don't think there's a critical mass of XEP-0184
implementations out there in the world. However, I'd be open to defining
the receipt/chunk mapping in more of an informational way in the
stox-chat spec.

What do other folks think?

> - Issue: Draft says gateway determines MSRP is supported before sending INVITE. How?

SIP OPTIONS...?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2013 19:50:39 -0400

> the good SIP UA implementations, some just crash in such cases :-) ).

You can make it sound easy by ignoring the details, but at the expense 
of quality of implementation.

The problem is that you may get multiple early dialogs, with media. At 
that time you don't know which one will answer first. So what do you do 
with the media while awaiting a 2xx?

You can't "pick one" without the risk that it is the wrong one.

You can "pick one" and switch it if it turns out to be the wrong one. 
But unless you relay the media the xmpp side will see a change, and so 
there must be some plan for how that is handled.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2013 19:52:16 -0400

>> - Issue: Draft says gateway determines MSRP is supported before sending INVITE. How?

Don't go there - its a bad plan.
There is no reasonable way to know in advance.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Aug 2013 19:15:17 -0600

> There is no reasonable way to know in advance.

Yeah, I know. It's a shame, but it's not something we can fix here...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 21 Aug 2013 08:52:47 +0200

> There is no reasonable way to know in advance.

Agree. 

/O

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 21 Aug 2013 09:17:52 +0200

On 8/21/13 1:50 AM, Paul Kyzivat wrote:
> that time you don't know which one will answer first. So what do you 
> do with the media while awaiting a 2xx?
>
My comments were for the remark related to multiple 200ok, I haven't 
said sending BYE for additional early dialogs.

For multiple early dialogs, the gateway has to maintain all of them 
until a 200ok. It's also implementation decision which of early media 
streams is sent to xmpp/jingle (again, it looks like it's mostly the 
first one from experiences out there).

Daniel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Aug 2013 15:03:17 -0400

> said sending BYE for additional early dialogs.

They are tightly connected issues.

> first one from experiences out there).

This is straightforward if the GW terminates/relays media.
But that is a cost.

A signaling-only GW can't easily or thoroughly prevent the multiple 
early media streams from reaching the xmpp client. (It may be able to 
send updates to all but one to stop their media, but that takes some 
time, and not all will support it.)

So either you mandate that the GW terminate the media, or else you have 
to acknowledge the situation and warn the xmpp client to be prepared.

	Thanks,
	Paul

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 21 Aug 2013 21:28:04 +0200

> They are tightly connected issues.

If you just look at parallel forking, but handling of them is totally 
different.

> So either you mandate that the GW terminate the media, or else you 
> have to acknowledge the situation and warn the xmpp client to be 
> prepared.
 From what's being repeated here, the idea is not to change existing 
protcols by enforcing new behaviour/support for features. It would be 
easier and more logical if changes can be made in both sides, but again, 
it's out of defined scope. Thus I guess the gateway should do stripping 
of what is not supported on the other side.

Since the issue is for calls from xmpp to sip, perhaps the multiple 
early media streams issue can be overcome by initiating the SIP side 
call with INVITE without SDP. The gateway needs to hold the SDP for ACK, 
but that should be no problem as I guess it has to be transaction 
stateful at least.

Daniel

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 21 Aug 2013 21:35:50 +0200

On Aug 21, 2013, at 9:03 PM, Paul Kyzivat wrote:

> A signaling-only GW can't easily or thoroughly prevent the multiple early media streams from reaching the xmpp client. (It may be able to send updates to all but one to stop their media, but that takes some time, and not all will support it.)
> 
> So either you mandate that the GW terminate the media, or else you have to acknowledge the situation and warn the xmpp client to be prepared.
> 

I see the subject hasn't changed, so are we talking about the -core draft or the -media draft here? The early media situation is indeed tricky when RTP is being used, but if we are dealing with chat, there should be no problem in keeping a few TCP connections alive until one of the dialogs has been confirmed. Also, when chat is in use the GW effectively terminates the media.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 16:35:45 -0400

> but that should be no problem as I guess it has to be transaction

That is indeed one way to solve the problem. But it will also be 
necessary to *not* support 100rel, or else the problem can still arise.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 16:40:59 -0400

> I see the subject hasn't changed, so are we talking about the -core draft or the -media draft here? The early media situation is indeed tricky when RTP is being used, but if we are dealing with cha…

There isn't any way to have a signaling only GW for xmpp-msrp.
So yes, you are right about that. Its only an issue for RTP media.

	Thanks,
	Paul

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 23 Aug 2013 11:55:59 +0200

> So yes, you are right about that. Its only an issue for RTP media.

Do, do you (or anyone) still think that any text on this regard is needed in the *core* document, or shall we just put that in the media one?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Aug 2013 11:11:13 -0600

> Do, do you (or anyone) still think that any text on this regard is needed in the *core* document, or shall we just put that in the media one?

I think this belongs in the -media document. Let's change the thread
name accordingly. :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Aug 2013 13:42:42 -0400

WFM