Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

[Christer Holmberg <[e-mail]>]

    >>>  I don't know. I'm trying to understand the intended usage and how it
    >>>  plays out in the example. If what I have in my address book for you is
    >>>  just your sip URI, then how do I figure out how to establish a chat
    >>>  session? How do I decide to use a data channel rather than MSRP over
    >>>  TLS?
    >> 
    >>     That is based on your local preferences, whatever your SIP (or whatever signaling protocol you use) client puts in the offer. In the same way it decides if it offers audio, video etc.
    >
    > I'll comment on this below.
    >
    > > And do I just somehow derive the msrp URL from your sip URL?
    >> 
    >> You don't need to derive it. The applications will create the msrp URLs and exchange them in O/A.
    >
    > What I meant was that the values have to come from somewhere. Where do 
    > they come from? In the example, the c= is 198.51.100.79, but the path 
    > has bob.example.com. How does that happen? Where did bob.example.com 
    > come from?
    >
    > ISTM that it would make the most sense to use the same value in both 
    > places. Or else use some fixed dummy placeholder value in path.

    Ok, so we'll put the same value in both places, if that makes things clearer. 

    >>> I guess if I am running in a browser and using WebRTC then I try a data
    >>> channel because there is no alternative I can use. But that isn't this
    >>> example. Must I have something else in my address book to tell me what
    >>> you support? Or should I be trying both in my invite and seeing what you
    >>> accept? (That also isn't this example.)
    >> 
    >>      You don't need to have anything. You send an offer, offer me MSRP, and if I support/accept it I send you MSRP back in the answer.
    >> 
    >>      This is no different from any other type of media...
    >
    > The problem is that there are multiple ways to set up a chat session 
    > under sip. This is much like the old problem of whether to IPv4 or IPv6 
    > in a c= line when you could do both. It took ICE to solve *that* problem 
    > in an acceptable way. AFAICT it isn't solved for chat. (The only likely 
    > solution that comes to mind is capability negotiation. But hardly 
    > anybody implements that do they?)
    >
    > I don't think it is necessary to solve it in this draft. But it would be 
    > good to at least acknowledge the problem.

    This draft does *not* cover how you establish the SCTP association, and how you choose between IPv4, IPv6 etc for that association. There is a separate draft for that.

    This draft does *not* even cover the generic procedures for negotiation a data channel. There is a separate draft for that. 

    This draft only describes the specifics associated with negotiation a data channel for MSRP usage. 

    Regards,

    Christer