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

[Paul Kyzivat <[e-mail]>]

On 5/14/20 12:46 PM, Christer Holmberg wrote:
> Hi,
>    
>    >  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.

>      > 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.

	Thanks,
	Paul