Subject: Re: [Simple] Sessmatch - an alternative approach

From: "Umang Singh" <[email-masked]>
Date: Tue, 7 Jun 2011 17:32:15 +0530

Hi Christer,
What about the scenario where 2 RFC 4975 compliant UA's try to establish
MSRP session on the basis of a=path with an ALG(more specifically SBC)
in the path? As SBC won't modify the a=path, the UA's can bypass the SBC
in the media path. Media anchoring would not work in this case. The
assumption that a firewall will drop any traffic not directed to the ALG
might not be a valid one specially if both the UA's are in the same
network.

Also, one of the basic functions of the SBC is topology hiding which
will not be done on the a=path attribute.

I don't agree with mandating the fallback mechanism either. Apart from
performance, another valid reason for not implementing the MSRP B2BUA
functionality in SBC's is the cost associated with the same.

Regards,
Umang

Date: Mon, 30 May 2011 21:40:25 +0200
From: Christer Holmberg <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Simple] Sessmatch - an alternative approach
Message-ID:
	
<[email-masked].
se>
	
Content-Type: text/plain; charset="us-ascii"

Hi,
 
Based on the issues that have been raised on sessmatch, I would like to
present a modified version, that solves some of the raised issues
related to security, backward compability, usage of the Require header
filed, and specifying of ALG behavior. It has the following advantages
over the current sessmatch mechanism:
 
1. Except for one case, that still requires MSRP B2BUA, it works with
"legacy" SIP-ALGs (that only modify the SDP c/m line, but not the
a=path) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA;
 
2. It works with name based authentication;
 
3. It works when a 4975 UA is behind a relay;

4. It works without a need for the offerer, or for the SIP-ALG, to use
the Require header field; and
 
5. It atually REMOVES the need to update the session matching procedure
in the first place :)

The idea is based on the very original sessmatch proposal, where a
sessmatch UA sends the TCP SYN for the MSRP connection based on the SDP
c/m-line, rather than the a=path.

BUT, the sessmatch UA still inserts the a=path MSRP URI into the MSRP
message, use it for name based authentication, and use if for session
matching - all according to existing RFC 4975 procedures.

Let's look at how it works.

Peer-to-peer (no SIP-ALG)
-----------------------------

As in the current sessmatch proposal, there is still full backward
compability. As the a=path and SDP c/m-line values will be identical, it
doesn't matter which the sessmatch UA uses for sending the TCP SYN. 

(In fact, we could even specify that the sessmatch UA uses the a=path in
case it is identical to the SDP c/m-line, and everything would be
identical to RFC 4975.)

SIP-ALG in the path
---------------------

1. A sessmatch UA sends a request that offers MSRP, and includes a
sessmatch support indication (option-tag, SDP attribute, or whatever we
choose).

2. The SIP-ALG modifies the SDP c/m-line of the offer, and the
corresponding answer, in order to anchor the MSRP media. The a=path is
NOT modified.

3. The sessmatch UA receives the answer from the remote UA.

4a. If the remote UA supports sessmatch, everthing is fine. Whoever is
"active" sends the TCP SYN according to the SDP c/m line (which points
to the ALG).

4b. If the remote UA does NOT support sessmatch, BUT is "passive"
(default if it does not support MSRP ACM), everything is fine. The
sessmatch sends the TCP SYN according to the SDP c/m line (which points
to the ALG).

4c. If the remote UA does NOT support sessmatch, AND is "active", things
will NOT work (unless SIP-ALG bypass is allowed), as the remote UA will
try to send the TCP SYN according to a=path (which points to the
sessmatch UA, rather than to the ALG).

5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending
a new offer where it does NOT include a sessmatch support indication.
The SIP-ALG, in order to support MSRP, will now have to enable MSRP
B2BUA functionality.

It works the same in the other direction, where the 4975 UA sends the
offer. If the 4975 UA becomes "active", the sessmatch UA will have to
send an offer without sessmatch indication.

Regards,
 
Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 7 Jun 2011 14:31:12 +0200

Hi,

> will not be done on the a=path attribute.

Is there any document/draft/spec where SBC recommended or mandatory features are listed?

> functionality in SBC's is the cost associated with the same.

Cost can't justify breaking an IETF protocol. What is your suggestion, just not having a fallback mechanism?

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 14:42:59 +0200

> will not be done on the a=path attribute.

In this case the ALG/SBC would do just nothing (just changing the "m"
line which means nothing in MSRP) so it would behave as a normal
"router" without anchoring the media. Then the MSRP communication
could work or not (depending on NAT scenario, MSRP relays, and so,
like in a normal environment).

What is the problem? in fact the "problem" you describe is the
*normal* behaviour of an MSRP communication when there is no ALG/SBC.
If an SBC cannot do its "magic", which is the problem? does such
hipotetic problem deserve an IETF specification?

> functionality in SBC's is the cost associated with the same.

As I said above, if the SBC cannot do its ugly magic then just do
nothing (things could work or not, as in the absence of the SBC). Or
become a MSRP B2BUA if it supports it. But *why* should a IETF
specification mandate this fallback mechanism?

I insist: if there is not an SBC the MSRP communication could work or
not, depending on NAT, presence of MSRP relays, etc). IETF does not
(and cannot) mandate a "fallback mechanism" in this normal scenario,
why should it mandate a "fallback mechanism" in case there is an
ALG/SBC? This sounds terrible, even more taking into account that
SBC/ALG's are specified nowhere and they basically breaks/corrupt
OSI/Internet layers and Internet protocols.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 14:49:14 +0200

> Cost can't justify breaking an IETF protocol. What is your suggestion, just not having a fallback mechanism?

If Alice and Bob, behind different NAT routers (no ALG) and with no
MSRP relays, try to establish an MSRP communication, it would fail
(obvious).
Should IETF mandate (MUST) that in this case the *normal* NAT router
(not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback mechanism"?
If the answer is "not" (and of course it's "not"), why should IETF
mandate such a mechanism for an ALG/SBC box?

So, if the ALG cannot anchor the MSRP media let it to behave as a
"normal IP/TCP box" which does not play at protocol level. If some
vendor wants to include "fallback mechanism behaving as a MSRP B2BUA"
it's ok, but why to mandate it?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 15:38:22 +0200

Hi,

I am not sure I understood the issues - maybe I should have waited for 30-40 additional e-mails before replying ;)

Anyway, let's start where we were before sessmatch:

If two 4975 UAs wanted to communicate, and there was an ALG present in the network, unless the ALG acted as a MSRP B2BUA (or, allowed bypass, which I don't think it very uncommon - there is a reason ALGs are inserted) things wouldn't not work. We can blame whoever, but that's a fact.

Now, let's see wehre we are today:

What sessmatch suggests, is that ALGs do implement MSRP B2BUA functionality. Not only will it allow sessmatch UAs to communicate with 4975 UAs in any scenario (again, the B2BUA functionality does not need to be applied in all cases), but it will also allow 4975 UAs to communicate with each other.

If a vendors chooses not to implement the specification, there is nothing we can do about that. If a vendor chooses not to implement it, they will be able to keep their ALGs, *AND* support MSRP, but without having to apply B2BUA functionality for every call. 

If you are a customer who needs an ALG, but also wants to provide MSRP, which vendor would you choose?

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
> Sent: 7. kesäkuuta 2011 15:49
> To: Saúl Ibarra Corretgé
> Cc: Umang Singh; [email-masked]
> Subject: Re: [Simple] Sessmatch - an alternative approach
> 
> >> I don't agree with mandating the fallback mechanism either. Apart 
> >> from performance, another valid reason for not 
> implementing the MSRP 
> >> B2BUA functionality in SBC's is the cost associated with the same.
> >>
> >
> > Cost can't justify breaking an IETF protocol. What is your 
> suggestion, just not having a fallback mechanism?
> 
> If Alice and Bob, behind different NAT routers (no ALG) and 
> with no MSRP relays, try to establish an MSRP communication, 
> it would fail (obvious).
> Should IETF mandate (MUST) that in this case the *normal* NAT 
> router (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback 
> mechanism"?
> If the answer is "not" (and of course it's "not"), why should 
> IETF mandate such a mechanism for an ALG/SBC box?
> 
> So, if the ALG cannot anchor the MSRP media let it to behave 
> as a "normal IP/TCP box" which does not play at protocol 
> level. If some vendor wants to include "fallback mechanism 
> behaving as a MSRP B2BUA"
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 15:47:14 +0200

Hi, 

>it's ok, but why to mandate it?

Let's be clear. Sessmatch is ONLY talking about ALGs that need to be able to modify the SDP in order to anchor media.

If they choose to instead behave like a normal IP/TCP box, or whatever, of course they don't need to implement B2BUA functionality.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 16:04:48 +0200

> If they choose to instead behave like a normal IP/TCP box, or whatever, of course they don't need to implement B2BUA functionality.

That's the point. And since ALG's are "anomalies" (don't take me
wrong), why should them be specified my an IETF document? and why
should such a document mandate nothing about an ALG?

I like the new specification proposal as ***it does not break nothing
that would work without the ALG box in the middle*** but, anyhow, why
to make an IETF specification about ALG's?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 7 Jun 2011 16:08:49 +0200

> mandate such a mechanism for an ALG/SBC box?

The sessmatch spec is targeted towards ALGs that modify the SDP for anchoring media, not home routers.

> it's ok, but why to mandate it?

The draft should probably change the title (since 'sessmatch' doesn't really apply now) and also mention that this is behavior specific to ALGs.

--
Saúl Ibarra Corretgé
AG Projects

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 10:09:26 -0400

Umang,

SBC's will do whatever service providers tell them. Solutions should
assume that the media will transverse an SBC.

Regards,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
[email-masked]
+1-609-903-3360

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Umang Singh
Sent: Tuesday, June 07, 2011 8:02 AM
To: [email-masked]
Subject: Re: [Simple] Sessmatch - an alternative approach

Hi Christer,

Regards,
Umang

	

Hi,

 

 

SIP-ALG in the path
---------------------

Regards,
 
Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 16:14:42 +0200

Hi, 

>>Let's be clear. Sessmatch is ONLY talking about ALGs that 
>>need to be able to modify the SDP in order to anchor media.
>>
>>If they choose to instead behave like a normal IP/TCP box, 
>>or whatever, of course they don't need to implement B2BUA 
>>functionality.
> 
>That's the point. And since ALG's are "anomalies" (don't take 
>me wrong), why should them be specified my an IETF document? 
>and why should such a document mandate nothing about an ALG?
> 
>I like the new specification proposal as ***it does not break 
>nothing that would work without the ALG box in the middle*** 
>but, anyhow, why to make an IETF specification about ALG's?

I think sessmatch provides a win-win situation, as it makes life easier for both those who deploy ALGs and those who use MSRP.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 7 Jun 2011 16:16:00 +0200

> to make an IETF specification about ALG's?

I think this is a lost battle. We can argue infinitely but vendors will do whatever they want to do. So lets seize the opportunity to contribute to a specification that doesn't break MSRP for the rest of us.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 16:16:40 +0200

2011/6/7 DOLLY, MARTIN C (ATTSI) <[email-masked]>:
> SBC's will do whatever service providers tell them.

Also breaking an existing protocol?

> Solutions should assume that the media will transverse an SBC.

Which "solutions" do you mean? Could you be more explicit please?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 16:18:52 +0200

> The sessmatch spec is targeted towards ALGs that modify the SDP for anchoring media, not home routers.

Right, but nothing will prevent home routers vendor to also implement
MSRP ALG the same as they've implemented poor/pathetic SIP ALG
"feature".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 16:19:50 +0200

Hi, 

>>Should IETF mandate (MUST) that in this case the *normal* 
>>NAT router (not a SIP ALG!!!) becomes a MSRP B2BUA as "fallback mechanism"?
>The sessmatch spec is targeted towards ALGs that modify the 
>SDP for anchoring media, not home routers.

If people think that is unclear I will do my best to make it more clear.

>>vendor wants to include "fallback mechanism behaving as a 
>>MSRP B2BUA" it's ok, but why to mandate it?
> 
>The draft should probably change the title (since 'sessmatch' 
>doesn't really apply now) and also mention that this is 
>behavior specific to ALGs.

The current working title is "Alternative Connection Establishment (ACE)" :)

The applicability section will make it clear that the procedures can be used when a UA is communicating with an ALG.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 7 Jun 2011 16:21:29 +0200

> MSRP ALG the same as they've implemented poor/pathetic SIP ALG

I think you are talking about two different kinds of ALGs: the ones that anchor media and the ones that want to "help" the user and "fix" SIP on his home router. 

--
Saúl Ibarra Corretgé
AG Projects

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 16:25:48 +0200

> assume that the media will transverse an SBC.

Dolly,

You are completely wrong. 

MSRP sessions flow just fine on the Internet without any explicit need for an SBC by using MSRP relays for NAT traversal.

No solution should be based on such broken assumption.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 16:47:27 +0200

> I think you are talking about two different kinds of ALGs: the ones that anchor media and the ones that want to "help" the user and "fix" SIP on his home router.

Right. But both of them could make usage of this spec, am I right?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 10:48:49 -0400

Adrian,

I guess you do not deal in reality...

Regards,

Martin Dolly

-----Original Message-----
From: Adrian Georgescu [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 10:26 AM
To: DOLLY, MARTIN C (ATTSI)
Cc: Simple WG
Subject: Re: [Simple] Sessmatch - an alternative approach

Dolly,

MSRP sessions flow just fine on the Internet without any explicit need
for an SBC by using MSRP relays for NAT traversal.

Adrian

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 7 Jun 2011 16:54:10 +0200

> Right. But both of them could make usage of this spec, am I right?

The spec should make clear that this mechanism should only be used by ALGs anchoring media.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 16:55:43 +0200

You must be kidding right? I have multiple MSTP sessions in progress as I write this email.

It is unbelievable how you can question the fact that MSRP exists outside of your narrow mind closed garden thinking.

Adrian

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Tue, 7 Jun 2011 10:59:30 -0400

Adrian,

I understand your use case, but it seems that you do not understand
ours. And without ours you will not have full
Deployment

Martin Dolly

-----Original Message-----
From: Adrian Georgescu [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 10:56 AM
To: DOLLY, MARTIN C (ATTSI)
Cc: Simple WG
Subject: Re: [Simple] Sessmatch - an alternative approach

You must be kidding right? I have multiple MSTP sessions in progress as
I write this email.

It is unbelievable how you can question the fact that MSRP exists
outside of your narrow mind closed garden thinking.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 17:01:29 +0200

> I guess you do not deal in reality...

Right, not all of us are big vendors, neither not all of us can break
an Internet protocol in favour of our interests and still promote an
IETF specification justifying that.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 17:15:58 +0200

One can do whatever is technically necessary inside a walled garden to increase throughput and use a protocol gateway to bridge to the outside if ever needed.  There is no need to invent a new MSRP related standard or MSRP connection model to make this possible. I t is between ATT and its vendors to agree on how to do this the best way not the task of an IETF WG.

Breaking well established standards RFC4975 and RFC4976 in order to satisfy your personal needs that has nothing to do with Internet is not right.

Adrian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 17:25:15 +0200

2011/6/7 DOLLY, MARTIN C (ATTSI) <[email-masked]>:
> ours.

Let's then speak about "your case" and "our case":

- Our case doesn't break your case.
- Your case *does* break our case (at least in the previous versions
of the draft, but it doesn't seem to worry you as per your previous
mails).
- Our case was before your case (as there are already IETF RFC's 4875 and 4876).
- Our case is pure Internet.
- Your case is an anomaly.

> And without ours you will not have full Deployment

We *already* have "full deployment" (or whatever that means).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 17:42:42 +0200

Hi,

>>> I think you are talking about two different kinds of ALGs: the ones that anchor media and the ones that >>>want to "help" the user and "fix" SIP on his home router.
>>

Absolutely.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 18:07:49 +0200

Hi,

>One can do whatever is technically necessary inside a walled garden to increase throughput and use a 
>protocol gateway to bridge to the outside if ever needed.  There is no need to invent a new MSRP related 
>standard or MSRP connection model to make this possible. I t is between ATT and its vendors to agree on 
>how to do this the best way not the task of an IETF WG.
>
>Breaking well established standards RFC4975 and RFC4976 in order to satisfy your personal needs that has 
>nothing to do with Internet is not right.

I don't know what is broken. The WG made a decisison, quite a while ago, to, rather than updating any of the existing RFCs, define sessmatch as an optional extension. 

Nobody is mandating you to implement it, and all your ongoing MSRP sessions will continue to work just fine.

But, quite many needs are fullfilled by this.

And, yes, if it was only between ONE operator and ONE vendor, they could sit down and agree on whatever. But, even in the so called walled gardens, there are products by multiple vendors, and traffic between multiple operators - and in many cases also connectivity to other types of networks, both so called walled gardens AND the so called "Internet" - where you of course never will find any ALGs...

And, ALGs are not only used for NAT traversal, and MSRP is not the only media for which NAT traversal is needed.

Regards,

Christer

---

From: "Umang Singh" <[email-masked]>
Date: Tue, 7 Jun 2011 21:55:09 +0530

Hi,
Requirements from SBC are defined in an IETF spec (http://tools.ietf.org/html/rfc5853). Topology hiding and media anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I think we should accept the presence and proliferation of SBCs and not call them an anomaly as it is specified in an IETF specification.

The reasons for not mandating a fallback which in turn would mean adding the MSRP B2BUA functionality in a SBC is that SBC could anchor media by just functioning as a TCP/IP relay just as it does for RTP traffic. The difference with MSRP is that MSRP packets contain MSRP URIs exchanged in signaling and matching of MSRP session to TCP connection is done on the basis of that. For a node like the SBC, functioning as a MSRP B2BUA has a huge performance overhead as compared to functioning as a TCP/IP relay. As the draft in question discusses possibilities of making MSRP work with such ALGs/SBCs in the path, I think this point is worthy of discussion.

Regards,
Umang

-----Original Message-----
From: Saúl Ibarra Corretgé [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 6:01 PM
To: Umang Singh
Cc: [email-masked]
Subject: Re: [Simple] Sessmatch - an alternative approach

Hi,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 18:29:55 +0200

> Nobody is mandating you to implement it, and all your ongoing MSRP sessions will continue to work just fine.

Hi Christer. I assume you are speaking about your recent new proposal
which does not break RFC 4875/4876, am I right? If not, I would not
like to resucit long threads already discussed about this topic :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 18:40:16 +0200

Hi,

>The reasons for not mandating a fallback which in turn would mean adding the MSRP B2BUA functionality in a SBC is that SBC could anchor media by just functioning as a TCP/IP relay just as it does for RTP traffic. The difference with MSRP is that MSRP packets 
>contain MSRP URIs exchanged in signaling and matching of MSRP session to TCP connection is done on the basis of that. For a node like the SBC, functioning as a MSRP B2BUA has a huge performance overhead as compared to functioning as a TCP/IP relay. As the 
>draft in question discusses possibilities of making MSRP work with such ALGs/SBCs in the path, I think this point is worthy of discussion.

I am not sure I understand. The whole idea is to allow the SBC to handle MSRP as any other media.

But, in some cases MSRP B2BUA functionality is needed.

Regards,

Christer

-----Original Message-----
From: Saúl Ibarra Corretgé [mailto:[email-masked]]
Sent: Tuesday, June 07, 2011 6:01 PM
To: Umang Singh
Cc: [email-masked]
Subject: Re: [Simple] Sessmatch - an alternative approach

Hi,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 7 Jun 2011 18:46:47 +0200

Dear Umang,

Mentioning an isolated entry into some obscure RFC to justify doing obvious damage to established IETF protocols which are operating just fine is a flawed argument.

Adrian

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 7 Jun 2011 18:54:52 +0200

Hi,

> Requirements from SBC are defined in an IETF spec (http://tools.ietf.org/html/rfc5853). Topology hiding and media anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I think we sho…

Thanks for the pointer, I'll go though it.

> The reasons for not mandating a fallback which in turn would mean adding the MSRP B2BUA functionality in a SBC is that SBC could anchor media by just functioning as a TCP/IP relay just as it does f…

An SBC can't anchor media just by mangling some headers and acting as a TCP/IP relay, not for MSRP. SBCs created this problem in the first place, but I can live with that, now we need a way to make everyone happy. The B2BUA fallback is needed in order for interoperability to be respected. It will not be used if all endpoints are aware of this specification and are behind ALGs. That is, if you deploy a network with an ALG and sessmatch (or ACE :-) ) enabled devices and you'll never use the B2BUA. But if I'm outside of your network and I want to comunicate with one of your users I'll need the B2BUA, in the cases previously described in this thread.

About the topology hiding, I see no way of doing it without acting as a B2BUA, since the path line should remain untouched. Thoughts, Christen and others?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Jun 2011 19:00:55 +0200

> Requirements from SBC are defined in an IETF spec (http://tools.ietf.org/html/rfc5853). Topology hiding and media anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I think we sho…

Just some phrases extracted from that RFC 5853:

   Even though many SBCs currently behave in ways that can break end-to-
   end security and impact feature negotiations, there is clearly a
   market for them.

   [...]

   The purpose of this document is to describe functions implemented in
   SBCs.  A special focus is given to those practices that conflict with
   SIP architectural principles in some way

   [...]

   The term SBC is relatively non-specific, since it is not standardized
   or defined anywhere.

So this is just an informational RFC which just talks about the SBC
(including the pain they produce!). It standarizes *nothing* and it
means absolutely nothing, at least for me.

Regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Jun 2011 13:16:41 -0500

(As individual)

> Requirements from SBC are defined in an IETF spec (http://tools.ietf.org/html/rfc5853). Topology hiding and media anchoring are mentioned in Section 3.1 and Section 3.2 respectively. I think we sho…

I think that RFC5853 is badly named. It doesn't define requirements in the sense of protocol or standards requirements. It's more of a collection of common behaviors of SBCs. Note that it is an informational RFC, not a standards track one.

Or more to the point, nothing in RFC 5853 should be taken to recommend or condone SBC behavior, other than places where it may suggest solutions to certain problems that might be more friendly to the SIP architecture.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2011 08:28:52 +0200

Hi, 

>I think that RFC5853 is badly named. It doesn't define 
>requirements in the sense of protocol or standards 
>requirements. It's more of a collection of common behaviors 
>of SBCs. Note that it is an informational RFC, not a 
>standards track one.
> 
>Or more to the point, nothing in RFC 5853 should be taken to 
>recommend or condone SBC behavior, other than places where it 
>may suggest solutions to certain problems that might be more 
>friendly to the SIP architecture.

I agree with Ben. 

RFC 5853 was meant to collect functions normally performed by SBCs, which could then be used as background information for future work in IETF.

And, eventhough the introduction of the sessmatch draft also gives a few examples of functions performed by SBCs, the focus of the "ALG assumptions" is more related to the protocol actions taken in order to anchor media, and not so much about the reasons why it's done.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 27 Jun 2011 10:14:07 +0300

Hi,

exactly. As Ben said, that RFC does not describe requirements SBCs need
to meet. Instead, it describes functions that can be commonly found in
SIP deployments. The "requirements" in the RFC are requirements on SIP
to support those functions in ways that do not break things.

Cheers,

Gonzalo