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

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

On 6/19/14, 9:52 PM, Peter Saint-Andre wrote:
> 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.

BTW, RFC 7247 does say:

    Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from
    SIP to XMPP will need to support TCP as the underlying transport
    protocol.  By contrast, as specified in [RFC3261], either TCP or UDP
    can be used as the underlying transport for SIP messages, and a given
    SIP deployment might support only UDP; therefore, a gateway from XMPP
    to SIP might need to communicate with a SIP server using either TCP
    or UDP.

But here we're talking about MSRP, so we might need similar text.

Peter