Re: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt

[Peter Saint-Andre <[e-mail]>]

On 6/19/14, 3:49 PM, Ben Campbell wrote:
> Hi Peter,
>
> [Disclaimer: this was a higher level review than for the previous
> version--I mainly looked to see how the previous discussions about
> the architecture rendered into the draft. ]
>
> This version is much improved. I think you've gotten the "FAIL" off
> of it. But of course, cleaning up the architecture reveals a few
> things :-)
>
> Section 4:
>
> I think the addition of section 4 helps a lot in general.
>
> The architecture treats the MSRP Conference server to be a monolithic
> thing.

As you pointed out later in this thread, this is a simplifying 
assumption to make the diagrams and explanations easier to follow.

> The result of this is, in the examples, all the SIP and MSRP
> traffic go to the sample place. That doesn't match the architecture
> from RFC 4975 and simple-chat, where the signaling (SIP) is separate
> from media (MSRP).  simple-chat talks in terms of a conference focus
> that handles the signaling side, and an MSRP switch that handles the
> media (MSRP) side.
>
> Now, it's perfectly okay to collocate those services into an MSRP
> Conference Server in real deployments, and okay to show it that way
> in this draft for the sake of simplicity. But it would be worth
> mentioning that in section 4, and maybe also mentioning that any
> interaction between the conference focus and MSRP switch are out of
> scope (and irrelevant) for this draft.
>
> Along the same line, I assume the public "SIP side" interface of the
> X2M gateway looks like a conference focus plus an MSRP switch to the
> outside world. Again, these could be logically separate, but
> co-located.

Exactly.

> Section 5 (and subsections)
>
> The diagram does not show the transport (e.g. TCP) connection
> establishment for MSRP. I think it would be useful to do so.

Agreed.

(It would also be useful to mention that we're assuming that an MSRP 
client uses the SIP "binding" to communicate with the MSRP conference 
server, see Section 6...)

> Also,
> the active endpoint (the one opening the transport connection) has to
> send an immediate MSRP SEND request once the connection is
> established. (I don't _think_ simple-chat extended that to allow an
> initial NICKNAME to replace that--but I may have missed it.)

Good catch.

> Section 6 (and subsections)
>
> The diagram in section 6 still has a "SIP Server".

I have to admit that I was pretty sleepy when I was editing that part of 
the document. :-)

> It's still not
> clear to me what that represents. It _could_ be a SIP Proxy, in which
> the MSRP session would skip it. I guess it could be an MSRP aware
> b2bua, in which case the MSRP session might also traverse it. It
> could be a combo of a SIP proxy and an RFC 4976 MSRP relay, but that
> would require additional MSRP signaling.
>
> I would suggest promoting it to some sort of SIP "service" or
> "service provider", which is more of a cloud than a box, and having
> the MSRP traffic skip it entirely. Or removing it entirely--there's
> no _protocol_ reason that a SIP user needs an outbound service
> provider (even though there might be perfectly good _deployment_
> reasons.)

If we remove it entirely (and I'm not opposed to that), is it safe to 
say that an MSRP client would connect directly to an MSRP-to-XMPP 
gateway? With my XMPP glasses on that doesn't make sense because in that 
world we always think of something (a "service" or "service provider" as 
you call it) acting as a network gatekeeper. However, I know that's not 
something we assume in SIP/MSRP architectures, so for our purposes here 
it's probably fine to delete the service provider from the diagrams in 
Section 6.

> I also think section 6 needs to show the same sort of MSRP connection
> establishment and initial SEND request as mentioned for 5.

Noted!

> Thanks!
>
> Ben.

Thanks for your continued reviews!

Peter