Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]

[Matt Ryan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Comments below.


On 5/27/14, 5:47 PM, Peter Saint-Andre wrote:
> Hi Ben, thanks for the feedback! Comments inline.
> 
> On 5/2/14, 2:44 PM, Ben Campbell wrote:
>> Hi,
>> 
>> Here's some belated comments:
>> 
(snip)
>> I see some issues with the SIP interaction. It may be that I am
>> confused by the two-gateway model, but you have a number of
>> transactions where the SIP responses do not go back to the same
>> entity that sent the SIP request. I suspect the intent was that
>> one gateway or the other would handle things depending on which
>> side initiated communication, but you've got dialogs (even
>> individual transactions) split across them. If this is intended,
>> then they would need to share SIP dialog and transaction state
>> somehow.
> 
> Hmmmmmm.
> 
> You make a good point. The diagrams here are not consistent with
> the architectural assumptions we described in the stox-core spec
> (now RFC 7247)...
> 
> ######################################################### #
> # #                 +-----+                               # #
> | S2X |                               # #   +-------------+ GW
> |<...........>+-------------+   # #   | SIP Server  +-----+
> | XMPP Server |   # #   | example.net |             +-----+
> example.com |   # #   +-------------+<***********>| X2S
> +-------------+   # #         *                     | GW  |  :
> # #         *                     +-----+  :              # #
> *                              :              # #
> [e-mail]             [e-mail]   # #
> # #########################################################
> 
> Legend: XMPP = ... or : SIP = *
> 
> Figure 1: Possible Gateway Deployment Architecture
> 
> Note that bidirectional communication between the SIP server and
> the XMPP server can be established over either SIP or XMPP.  If the
> XMPP user initiates the interaction, then the XMPP server would
> invoke its XMPP-to-SIP gateway; thus, the communication would occur
> over SIP. If the SIP user initiates the interaction, then the SIP
> server would invoke its SIP-to-XMPP gateway; thus, the
> communication would occur over XMPP.
> 
> That is, the MSRP-to-XMPP gateway doesn't belong as an entity in
> the protocol flow for XMPP MUC to MSRP Multi-party Messaging
> Session (Section 4), and the XMPP-to-MSRP gateway doesn't belong in
> the protocol flow for MSRP Multi-party Messaging Session to XMPP
> MUC (Section 5).If we correct this error, I think most of the
> feedback you provide below can be easily addressed.


This is one of the concerns I also raised in my review of
draft-ietf-stox-chat-06 on 5/12/14, and why I raised my subsequent
question about communication between STOX-capable and non-STOX-capable
entities.

The situation is actually a bit worse:  If the XMPP-to-SIP gateway
sends a SIP invite to the SIP server (or MSRP conference in the
groupchat case) on the receiving end, the SIP session will not get
established until the XMPP-to-SIP gateway receives a 200 OK from the
SIP server, and it will continue to retry this INVITE until the
session is established.

Keeping state on the XMPP side might help (other than you still have
the unnecessary retransmits), but as Peter pointed out, simply
removing the MSRP-to-XMPP gateway in this protocol flow would then
result in the 200 OK returning to the XMPP-to-SIP gateway, which would
complete the establishment of the session also.


- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  [e-mail]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTiOw5AAoJEPyFiw1u4O0c/mIIAKDTV4SAwORIuL3GwfqfA2Vg
AKeGMgmKT9RTLhXnh3YjJxetN1XJ9spGcaVUIv4xvlDnAdqqeURiR1jc8uSkLtl5
YPdzERgPrL4tLcum2+/0cVneRvgLqHfwj9O88im9GRtuMTZ8Ny6Vb0+rHHylq7Y+
zKo88Zi3myT7MNXZioa7KTxt+xtTDQz2LxhCkuLeK+Sr/dkG+aQOjI4ZYsPSE7Ne
aatqCXqA3gUbWVe1YmUhCzkSjVTun6OWRkxDvxG9QLIQkFRZnu96FPSrJETYYYwf
QXAyX14yr9beq6NUxUDdsCZJ0URL/mHeuSVe0isG+MhBXHwfNIjEebslh3BoACY=
=bt4O
-----END PGP SIGNATURE-----