headers
Gaurav Nangla | 1 Apr 2011 04:51

Alternate Connection Model Query

Hello,

I've got an alternate connection model query.

Suppose there's a SBC/B2BUA lying in the signalling and media paths between two MSRP UAs.
The SBC manipulates the 'setup' attribute in a manner such that both parties can setup a MSRP session despite them both being behind NATs/firewalls.

i.e. 'a=setup:active' is received in OFFER from UA1, 'actpass' is sent in OFFER to UA2 by the SBC, 'active' is received from UA2 in ANSWER, 'passive' is sent in ANSWER to UA1 by the SBC.  

What this means is that the SBC will be receiving SYNs from both the UAs and handling them using the 'TCP splicing' technique.
It's basically making both the UAs think that they've each initiated and setup a MSRP TCP connection.

Scenario further described in greater detail at: 
http://lists.ag-projects.com/pipermail/blink/2011-March/001263.html


Q1> Does this mean that the alternate connection model is sufficient by itself for an end to end MSRP session?
Q2> Also on a related note, is a UA restricted (by the specs) from responding to a SEND request received while it's waiting for a response to its own unanswered SEND request?


Gaurav




_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 0 comments |
headers
Ben Campbell | 5 Apr 2011 23:23
Favicon

draft-ietf-simple-msrp-sessmatch-10 Issue

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.
Permalink | Reply | 5 comments |
headers
Hisham Khartabil | 6 Apr 2011 04:07
Picon

Re: draft-ietf-simple-msrp-sessmatch-10 Issue

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 <ben <at> nostrum.com> 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.

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.

_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 1 comment |
headers
Ben Campbell | 6 Apr 2011 04:18
Favicon

Re: draft-ietf-simple-msrp-sessmatch-10 Issue


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.


Hisham

On 6 April 2011 07:23, Ben Campbell <ben <at> nostrum.com> 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.

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.


_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 0 comments |
headers
Ben Campbell | 6 Apr 2011 04:31
Favicon

draft-ietf-simple-msrp-sessmatch-10 Issue

(oops, managed to miss Christer in the CC list. Sorry for the repeat)

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.
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 17 comments |
headers
Christer Holmberg | 6 Apr 2011 08:20
Picon
Favicon

Re: draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

I vote for option 2). I provides a mechanism to negotiate the usage of sessmatch, and the possibility for an
SBC to perform fallback. Whether it does so, as Ben said, is an implementation/policy issue, but I can
inform that there is at least one vendor considering such fallback support.

Option 3) is very bad, considering that there are already at least two other SDOs (OMA and 3GPP) refering to
sessmatch (and have been doing so for quite a while already).

Option 1) is also bad, as it will cause confusing and additional work in other SDOs, and in the market in
genral. And, option 2) provides the same outcome as option 1).

Regards,

Christer

________________________________________
From: Ben Campbell [ben <at> nostrum.com]
Sent: Wednesday, April 06, 2011 5:31 AM
To: Simple WG
Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

(oops, managed to miss Christer in the CC list. Sorry for the repeat)

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.
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 2 comments |
headers
R.Jesske | 6 Apr 2011 09:39
Picon

Re: draft-ietf-simple-msrp-sessmatch-10 Issue

I support Option 2)

Thanks

Roland

> ________________________________________
> From: Ben Campbell [ben <at> nostrum.com]
> Sent: Wednesday, April 06, 2011 5:31 AM
> To: Simple WG
> Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
> Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue
>
> (oops, managed to miss Christer in the CC list. Sorry for the repeat)
>
> 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.
> _______________________________________________
> Simple mailing list
> Simple <at> ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>
Permalink | Reply | 1 comment |
headers
Atle Monrad | 6 Apr 2011 10:49
Picon
Favicon

Re: draft-ietf-simple-msrp-sessmatch-10 Issue

Folks

As the new 3GPP / IETF coordinator, i can confirme that there is a 3GPP dependency on sessmatch since a quite
long time.

I hope that we can solve the issue soon. Please don't drop or completely restart the topic.

I would also like to support option 2) for the reasons outlined by Christer below.

/atle 

________________________________ 

Atle Monrad
3GPP CT1 Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: simple-bounces <at> ietf.org [mailto:simple-bounces <at> ietf.org] On Behalf Of Christer Holmberg
Sent: 6. april 2011 08:20
To: Ben Campbell; Simple WG
Cc: Cullen Jennings; John <at> core3.amsl.com; Adam Roach; John Mattsson
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

I vote for option 2). I provides a mechanism to negotiate the usage of sessmatch, and the possibility for an
SBC to perform fallback. Whether it does so, as Ben said, is an implementation/policy issue, but I can
inform that there is at least one vendor considering such fallback support.

Option 3) is very bad, considering that there are already at least two other SDOs (OMA and 3GPP) refering to
sessmatch (and have been doing so for quite a while already).

Option 1) is also bad, as it will cause confusing and additional work in other SDOs, and in the market in
genral. And, option 2) provides the same outcome as option 1).

Regards,

Christer

________________________________________
From: Ben Campbell [ben <at> nostrum.com]
Sent: Wednesday, April 06, 2011 5:31 AM
To: Simple WG
Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

(oops, managed to miss Christer in the CC list. Sorry for the repeat)

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.
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 1 comment |
headers
Schmidt, Christian 1. (NSN - DE/Munich | 6 Apr 2011 12:58

Re: draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

option 2 seems to be the right choice.

/Christian

-----Original Message-----
From: simple-bounces <at> ietf.org [mailto:simple-bounces <at> ietf.org] On Behalf
Of ext Atle Monrad
Sent: Wednesday, April 06, 2011 10:49 AM
To: Ben Campbell; Simple WG
Cc: Cullen Jennings; John <at> core3.amsl.com; Adam Roach; John Mattsson
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Folks

As the new 3GPP / IETF coordinator, i can confirme that there is a 3GPP
dependency on sessmatch since a quite long time.

I hope that we can solve the issue soon. Please don't drop or completely
restart the topic.

I would also like to support option 2) for the reasons outlined by
Christer below.

/atle 

________________________________ 

Atle Monrad
3GPP CT1 Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: simple-bounces <at> ietf.org [mailto:simple-bounces <at> ietf.org] On Behalf
Of Christer Holmberg
Sent: 6. april 2011 08:20
To: Ben Campbell; Simple WG
Cc: Cullen Jennings; John <at> core3.amsl.com; Adam Roach; John Mattsson
Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,

I vote for option 2). I provides a mechanism to negotiate the usage of
sessmatch, and the possibility for an SBC to perform fallback. Whether
it does so, as Ben said, is an implementation/policy issue, but I can
inform that there is at least one vendor considering such fallback
support.

Option 3) is very bad, considering that there are already at least two
other SDOs (OMA and 3GPP) refering to sessmatch (and have been doing so
for quite a while already).

Option 1) is also bad, as it will cause confusing and additional work in
other SDOs, and in the market in genral. And, option 2) provides the
same outcome as option 1).

Regards,

Christer

________________________________________
From: Ben Campbell [ben <at> nostrum.com]
Sent: Wednesday, April 06, 2011 5:31 AM
To: Simple WG
Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

(oops, managed to miss Christer in the CC list. Sorry for the repeat)

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.
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 0 comments |
headers
Nancy Greene | 6 Apr 2011 16:59
Picon
Favicon

Re: draft-ietf-simple-msrp-sessmatch-10 Issue

I support option 2. 

Nancy 

-----Original Message-----
From: simple-bounces <at> ietf.org [mailto:simple-bounces <at> ietf.org] 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,

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.
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
Permalink | Reply | 0 comments |

Gmane