Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Apr 2011 16:23:01 -0500

Hi,

A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a face-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a backwards compatibility issue.

Specifically, an MSRP user agent implementing the sessmatch description that is behind an SBC or ALG that operates as the draft envisions cannot interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. The issue is not caused by the sessmatch extension per se, but by the SBC/ALG. However, the sole purpose of this extension is to allow such behavior.

We agreed that this was a backwards compatibility issue, and as such would not be acceptable without some negotiation mechanism.

We discussed the following options. Note that no one option was favored by all present--I will let people speak individually as to their preferences.

1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally different protocol from base MSRP

2) Create a SIP option tag that indicates that a UA both supports sessmatch, and does not use an MSRP relay.

3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, it must rewrite the MSRP header fields in a manner similar to an MSRP Relay.

The chairs would appreciate a quick resolution to this issue, and request anyone who cares please make their opinions known on the SIMPLE list as soon as possible.

Thanks!

Ben.

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 6 Apr 2011 12:07:12 +1000

It sounds like options 1 and 2 will not allow interoperability between the 2
UAs. I least hate option 3, but do we need to document that?

Hisham

On 6 April 2011 07:23, Ben Campbell <[email-masked]> wrote:

> Hi,
>
> A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a
> face-to-face discussion of issues related to
> draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a backwards
> compatibility issue.
>
> Specifically, an MSRP user agent implementing the sessmatch description
> that is behind an SBC or ALG that operates as the draft envisions cannot
> interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. The
> issue is not caused by the sessmatch extension per se, but by the SBC/ALG.
> However, the sole purpose of this extension is to allow such behavior.
>
> We agreed that this was a backwards compatibility issue, and as such would
> not be acceptable without some negotiation mechanism.
>
> We discussed the following options. Note that no one option was favored by
> all present--I will let people speak individually as to their preferences.
>
> 2) Create a SIP option tag that indicates that a UA both supports
> sessmatch, and does not use an MSRP relay.
>
> 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP,
> it must rewrite the MSRP header fields in a manner similar to an MSRP Relay.
>
> The chairs would appreciate a quick resolution to this issue, and request
> anyone who cares please make their opinions known on the SIMPLE list as soon
> as possible.
>
> Thanks!
>
> Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Apr 2011 21:18:19 -0500

On Apr 5, 2011, at 9:07 PM, Hisham Khartabil wrote:

> It sounds like options 1 and 2 will not allow interoperability between the 2 UAs.

Option 2 could conceivably allow the UA behind the SBC to fall back to standard behavior. We all know a provider using an SBC is unlikely to allow the UA to do that-but that's a policy problem rather than a technical one. But in the most likely case, you at least get an explicit signaling error, which is marginally better than an inexplicable media failure. 

> I least hate option 3, but do we need to document that?

You are probably right on the documentation bit--we don't need to specify how SBCs work with or without sessmatch.

---

From: Nancy Greene <[email-masked]>
Date: Wed, 6 Apr 2011 10:59:09 -0400

I support option 2. 

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: April-05-11 5:23 PM
To: Simple WG
Cc: Cullen Jennings; Adam Roach; John Mattsson
Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

Thanks!

Ben.
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: nagesh kumar <[email-masked]>
Date: Thu, 7 Apr 2011 22:52:05 +0530

copied the maling list...

Regards
Nagesh
On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar <[email-masked]> wrote:

> Experts,
>
> Are we essentially ruling out a deployment which has SBCs and MSRP Relays?
> (I didn't come across such a deployment till now - just making sure that it
> indeed is the case).
>
> If that is case, can we not take the presence of a=setup attribute to
> support ACM model itself as a declaration of sess-match capabilitiy? If UA
> is using MSRP relay, there is no need to use ACM.
>
> Regards
> Nagesh
>
>   On Wed, Apr 6, 2011 at 8:29 PM, Nancy Greene <[email-masked]>wrote:
>
>> I support option 2.
>>
>> Nancy
>>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Apr 2011 12:27:54 -0500

(as individual)

On Apr 7, 2011, at 12:22 PM, nagesh kumar wrote:

> Are we essentially ruling out a deployment which has SBCs and MSRP Relays? (I didn't come across such a deployment till now - just making sure that it indeed is the case).
>  
> If that is case, can we not take the presence of a=setup attribute to support ACM model itself as a declaration of sess-match capabilitiy? If UA is using MSRP relay, there is no need to use ACM.

I don't think the use of ACM implies the use of sessmatch, and there are a subset of ACM scenarios that should be able to work with relays.  Also, while sessmatch may not be commonly used without ACM, it's still certainly possible. So I don't think the setup attribute is sufficient. It is worth discussing whether signaling sessmatch support belongs in a SIP option tag vs SDP.

[...]

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Apr 2011 21:56:35 +0200

Hi,

ACM and sessmatch are two separate functions - and that's one of the reasons we at one point decided to describe them in separate drafts.

ACM can be useful when a UA is behind a NAT - no matter whether there is an SBC or not.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: 7. huhtikuuta 2011 20:28
To: nagesh kumar
Cc: Simple WG
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

(as individual)

Regards
Nagesh
On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar <[email-masked]<mailto:[email-masked]>> wrote:
Experts,

[...]

Thanks!

Ben.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 12 Apr 2011 10:22:53 +0200

> The chairs would appreciate a quick resolution to this issue, and request anyone who cares please make their opinions known on the SIMPLE list as soon as possible.

Correct me if I'm wrong, but we need sessmatch in order to allow
interoperability between 2 UAs that are not using TLS name based auth
and have a SBC/ALG between them, right?

If this is the case, how is this scenario envisioned to grow in deployment?

Option 2 would be my choice if the sessmatch spec is wanted/needed,
though as someone pointed out, there would be issues if SBC/ALG
manufacturers don't implement a fallback mechanism.

I agree with Hisham in that option 3 is the one I less hate. How
disruptive would it be to give up on sessmatch given that 3GPP/OMA
already refer to it? If answer to this is "well, not that much" then
I'd go option 3, else I'd go for option 2.

That's my 2 cents,

-- 
/Saúl
http://saghul.net | http://sipdoc.net