Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs

From: Hisham Khartabil <[email-masked]>
Date: Mon, 2 Mar 2009 13:39:08 +1100

I don't agree with that. We cannot have two MSRP clients using SIP and
SDP as signalling protocols not be able to communicate, just like we
cannot have two G.711 clients using SIP and SDP as signalling
protocols not be able to communicate.

To me, the requirement seems strong that we need to have
communicability between an msrp-acm client and msrp-relay client. I
suggest Hadriel and Christer start working on use cases and call flows
to that effect.

Regards,
Hisham

2009/2/25 Hadriel Kaplan <[email-masked]>:
>
>
>> -----Original Message-----
>> From: Ben Campbell [mailto:[email-masked]]
>> Sent: Tuesday, February 24, 2009 9:35 AM
>>
>> This quickly returns to the "if we go down this path, we have
>> effectively deprecated MSRP relays." situation.  If the community
>> wants to do that, so be it. But I really don't want to split the
>> standard so that we have two implementation choices that can't
>> interoperate.
>
> I don't think that's what we're saying.  We have a session-creating rendezvous protocol (SIP) with address advertisement and capability negotiation (SDP) which allows us to offer different media-layer connection schemes and attributes.  So we're saying let SIP and SDP do their job - let them advertise what each side supports.  That's what they do for codecs, srtp, audio/video, etc.  If the two sides each support incompatible choices, then sure it won't work - just like it won't if we don't have common media capabilities.
>
> -hadriel
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 1 Mar 2009 22:11:02 -0500

> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Sunday, March 01, 2009 9:39 PM
>

But you do have that situation for two "G.711" clients, right now, all over the place.  First, "G.711" is actually PCMU vs. PCMA as you know, and those two don't talk to each other.  Even if you do both, you can indicate RTP/AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF - and none of them talk to each other.  And there are at least 3 different forms of SRTP key exchange, which don't interoperate.  But more to the point my analogy is that this isn't G.711 vs G.711 - this is more like RTP vs. SRTP, or UDP vs. RUDP.  The two modes are inexorably non-interoperable.

> suggest Hadriel and Christer start working on use cases and call flows

Why does the requirement seem strong to you?

-hadriel

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 2 Mar 2009 15:20:29 +1100

The requirement is strong because 90% of the people I talked to
off-line agree with it. We can take a poll on the mailing to see how
strong this requirement and satisfy those who don't believe it is.

Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 2 Mar 2009 15:30:23 +1100

2009/3/2 Hadriel Kaplan <[email-masked]>:
> But you do have that situation for two "G.711" clients, right now, all over the place.  First, "G.711" is actually PCMU vs. PCMA as you know, and those two don't talk to each other.  Even if you do both, > you can indicate RTP/AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF - and none of them talk to each other.  And there are at least 3 different forms of SRTP key exchange, which don't interoperate.  But
> more to the point my analogy is that this isn't G.711 vs G.711 - this is more like RTP vs. SRTP, or UDP vs. RUDP.  The two modes are inexorably non-interoperable.
>

Sorry, I meant to compare RTP with MSRP.

PCMU and PCMA are really different codecs and is like comparing
text/plain with image/jpeg.

What are talking about here is 2 ways to signal an initiation of a
session that uses the same MSRP protocol to carry media.

Hisham

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 1 Mar 2009 23:46:10 -0500

> Sent: Sunday, March 01, 2009 11:30 PM
>

Not as I read it.  The MSRP protocol itself would be changed/different on the client.  The msrp-acm client is receiving MSRP messages with a from-path url not matching the remote ip:port it's receiving from, and sending them out to a remote ip:port not matching it's to-path url.  No?
It's effectively a different "codec".  It's a small difference, somewhat like u-law/a-law companding, but non-interoperable.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 00:01:10 -0500

> Sent: Sunday, March 01, 2009 11:20 PM
>

To date I have not seen a proposal for how the mechanism can interwork with current rfc4976 MSRP Relays.  I'm all in favor of making it work with such, but I don't know how to do the impossible.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Mar 2009 07:03:28 +0100

Hi,

One way of making it work is to use a B2BUA which does interworking
between msrp-acm and msrp-relay.

I think that would be a satisfying solution, considerering the relay
deployment situation.

Regards,

Christer 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 2. maaliskuuta 2009 7:01
> To: Hisham Khartabil
> Cc: Ben Campbell; Christer Holmberg; Simple WG
> Subject: RE: [Simple] msrp-acm: Using MSRP with SBCs/ALGs
> 
> 
> 
> To date I have not seen a proposal for how the mechanism can 
> interwork with current rfc4976 MSRP Relays.  I'm all in favor 
> of making it work with such, but I don't know how to do the 
> impossible.
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Mar 2009 01:10:09 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, March 02, 2009 1:03 AM
>

Sure, I'm cool with that if it will move us forward.

-hadriel

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 02 Mar 2009 15:43:27 +0100

I am leaning towards the solution pointed below by Christer. Facts:

- While we have indications that MSRP relays will not ever take, there is 
  one weak signal of it (msrprelay.org) which deserves our respect.
- Those architectures who could have embraced MSRP relays decided to do 
something else (a la MSRP ACM).
- The industry in general is reluctant to use special mechanisms for NAT 
traversal with MSRP, and is willing to use existing general mechanisms.

So, I think MSRP ACM has to move forward, and it has to provide a 
mechanism to interoperate with MSRP relays. This is going to be an update 
to the MSRP relay spec., similarly to what many RFCs do with their 
canonical specifications.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain