Subject: [Simple] CEMA: ALG definition proposal

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 13:53:17 +0200

Hi,

In order to avoid confusion, missunderstandings, and general discussions about what an ALG does and doesn't do, I have put togheter some definition text which explains what we mean by ALG within the scope of the sessmatch draft.

------------

ALG:    Within the scope of this document, ALG refers to a network SIP device that modifies SDP media address:port information in
order to steer (anchor) media flows described in the SDP, including TCP connections used for MSRP communication, through a
media proxy function controlled by the SIP device. Other SIP related functions (e.g. related to routing, modification of SIP information
etc) performed by the SIP device, and whether it device creates separate SIP dialogs in each direction or not, is outside the scope
of the definition. Section 5 describes assumptions regarding how the ALG handles MSRP in order to support the extension defined
in this document.

------------

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 14:23:30 +0200

2011/6/15 Christer Holmberg <[email-masked]>:
> In order to avoid confusion, missunderstandings, and general discussions
> about what an ALG does and doesn't do, I have put togheter some definition
> text which explains what we mean by ALG within the scope of the sessmatch
> draft.
>
> ------------
>
> ALG:    Within the scope of this document, ALG refers to a network SIP
> device that modifies SDP media address:port information in
> order to steer (anchor) media flows described in the SDP, including TCP
> connections used for MSRP communication, through a
> media proxy function controlled by the SIP device. Other SIP related
> functions (e.g. related to routing, modification of SIP information
> etc) performed by the SIP device, and whether it device creates separate SIP
> dialogs in each direction or not, is outside the scope
> of the definition. Section 5 describes assumptions regarding how the ALG
> handles MSRP in order to support the extension defined
> in this document.
>
> ------------

Hi Christer, this text is nice, but does it mean that this draft will
not cover those layer 3 devices (i.e. NAT routers) which perform ugly
SIP inspection/modification? (this is what I call "SIP ALG routers").

I do hate those devices but my question is, why not to include them?
Unfortunately they do exist. If they are not covered in the draft it
seems that the draft is just writen in favour of 5-6 big vendors in
all the world building complex SBC devices.

On the other side, it could be just better to ignore such SIP ALG
routers as I also would hate them to be quoted in any IETF spec.

Honestly I don't know the purpose of my comment :)

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 14:45:34 +0200

Hi, 

>>------------
>>
>> ALG:    Within the scope of this document, ALG refers to a 
>> network SIP device that modifies SDP media address:port information in order to 
>> steer (anchor) media flows described in the SDP, including TCP 
>> connections used for MSRP communication, through a media proxy 
>> function controlled by the SIP device. Other SIP related functions 
>> (e.g. related to routing, modification of SIP information
>> etc) performed by the SIP device, and whether it device creates 
>> separate SIP dialogs in each direction or not, is outside 
>> the scope of the definition. Section 5 describes assumptions regarding 
>> how the ALG handles MSRP in order to support the extension defined in this 
>> document.
>>
>> ------------
> 
>Hi Christer, this text is nice, but does it mean that this 
>draft will not cover those layer 3 devices (i.e. NAT routers) 
>which perform ugly SIP inspection/modification? (this is what 
>I call "SIP ALG routers").
> 
>Unfortunately they do exist. If they are not covered in the 
>draft it seems that the draft is just writen in favour of 5-6 
>big vendors in all the world building complex SBC devices.
> 
>On the other side, it could be just better to ignore such SIP 
>ALG routers as I also would hate them to be quoted in any IETF spec.
> 

And I am not sure I understand it :)

The purpose of the definition text was that we don't need to have general discussions about what types of nodes are included or excluded, or that the name we use means something else. We now say what we mean by ALG within the scope of sessmatch.

And, the only thing we care about is that they anchor MSRP media, as described in the definition text.

Whatever else they do, or whatever else they might be called, doesn't matter from a sessmatch/CEMA perspective.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 15:01:19 +0200

> The purpose of the definition text was that we don't need to have general discussions about what types of nodes are included or excluded, or that the name we use means something else. We now say wh…

Ok, so what about NAT routers (which are not SIP nodes, of course)
with SIP ALG? couldn't them make usage of CEMA?

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 15:02:40 +0200

> with SIP ALG? couldn't them make usage of CEMA?

Of course such ugly devices could never fallback to MSRP B2BUA.

Ok, forget my questions please, it's better tu assume that SIP ALG
routers don't exist.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 15 Jun 2011 15:04:35 +0200

> with SIP ALG? couldn't them make usage of CEMA?

No, because their purpose is not media anchoring.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 15 Jun 2011 15:06:14 +0200

Hi,

> In order to avoid confusion, missunderstandings, and general discussions about what an ALG does and doesn't do, I have put togheter some definition text which explains what we mean by ALG within th…

I think this is an accurate description of what an ALG means in *this* particular case.

+1

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 15:21:40 +0200

> No, because their purpose is not media anchoring.

I don't understand your point. A NAT router does "anchor" any
communication from a user in the LAN with an external server/user. In
addition, painful SIP ALG NAT routers perform criminal replacements in
SIP messages so signalling and media "can" work when a user is behind
NAT.

So a SIP ALG router could perfectly implement CEMA and modify the SDP
so an external MSRP client could talk to a MSRP client in the LAN
(let's suppose there is no MSRP relay neither the external user
supports announcing MSRP passive mode).

Am I wrong? maybe the above is not "anchoring"?

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 15:34:35 +0200

Hi, 

>communication from a user in the LAN with an external 
>server/user. In addition, painful SIP ALG NAT routers perform 
>criminal replacements in SIP messages so signalling and media 
>"can" work when a user is behind NAT.
> 
>So a SIP ALG router could perfectly implement CEMA and modify 
>the SDP so an external MSRP client could talk to a MSRP 
>client in the LAN (let's suppose there is no MSRP relay 
>neither the external user supports announcing MSRP passive mode).
> 

If the device anchors MSRP media, as described in the proposed defintion text, then it is covered by the defintion.

I don't see how we would be able to start excluding certain devices based on OTHER functions they perform, that are not related to the CEMA extension.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 15 Jun 2011 15:41:22 +0200

Hi,

> SIP messages so signalling and media "can" work when a user is behind

No. Home routers don't anchor media. Anchoring means adding yourself in the middle for inspecting the media, measuring quality, etc.

> Am I wrong? maybe the above is not "anchoring"?

I'd say that this spec does not intend to cover routers that perform some modifications to the SIP messages in order to 'fix' NAT issues, even if they make it worse :-) This spec is targeted at SIP entities that insert themselves in the media path.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 15:42:21 +0200

>From your first mail:

> ALG:    Within the scope of this document, ALG refers to a network SIP device that modifies SDP media address:port information in order to steer (anchor) media flows described in the SDP

The text clearly defines an ALG as a real SIP device (which can be a
proxy, a pseudo-proxy, a B2BUA.... whatever, but something routeable
at SIP level).

A SIP ALG NAT router is not a SIP device but IMHO it could perform SDP
replacement in order to "allow" MSRP communication between internal
(NATted) and external users.

So, does this draft cover SIP ALG NAT routers? Maybe it occurs that
the "ALG" definition above does not mean that the draft only covers
those "ALG" devices.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 15:46:16 +0200

> I'd say that this spec does not intend to cover routers that perform some modifications to the SIP messages in order to 'fix' NAT issues, even if they make it worse :-) This spec is targeted at SIP…

What would prevent a SIP ALG router to insert itself in the media path
instead of doing an ugly IP replacement in the SDP?

Also I don't think that the motivation for anchoring media (inspecting
the media, measuring quality, solving NAT) gets importance here.

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

---

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

Hi,

> instead of doing an ugly IP replacement in the SDP?

Nothing, really.

> the media, measuring quality, solving NAT) gets importance here.

It's actually the key point :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 16:21:36 +0200

Hi,

Would it be more clear if the text said "SIP stateful device"?

Because, I don't think a non-SIP device can be SIP stateful :)

Regards,

Christer 

> -----Original Message-----
> From: Saúl Ibarra Corretgé [mailto:[email-masked]] 
> Sent: 15. kesäkuuta 2011 17:01
> To: Iñaki Baz Castillo
> Cc: Christer Holmberg; [email-masked]
> Subject: Re: [Simple] CEMA: ALG definition proposal
> 
> Hi,
> 
> >> I'd say that this spec does not intend to cover routers 
> that perform some modifications to the SIP messages in order 
> to 'fix' NAT issues, even if they make it worse :-) This spec 
> is targeted at SIP entities that insert themselves in the media path.
> >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 16:44:14 +0200

> Because, I don't think a non-SIP device can be SIP stateful :)

Right, just Chuck Norris can do that.

But if you use such term, then SIP ALG routers are discarded from this
spec. I still wonder why a SIP ALG router could not use this spec.
Let's suppose:

- alice (which supports CEMA) in public Internet sends INVITE to bob
(behind NAT).
- bob's SIP ALG painful-router replaces the c= line with its public IP
and set some port in m= line of MSRP stream (CEMA?).
- Maybe the router also destroys SIP signalling or whatever, but "that
is out of the scope of this mail". :)
- alice is also CEMA compliant (Big-Vendor-$$$$$
Professional-Certified-€€€€€-Phone) so MSRP works.

In this example, the node performing CEMA is not a SIP device. My
question is: should this draft cover such posibility? or should it
deny it?

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 15 Jun 2011 16:54:13 +0200

Ideally

This draft must not be used in implementations over the public Internet where MSRP protocol has already provisions in place to handle traffic for users behind NAT-ed routers by using standard MSRP Relays. The scope must be narrowed down to 3GPP closed network deployments only where there is no need or requirement to use Relays. 

On Jun 15, 2011, at 4:44 PM, Iñaki Baz Castillo wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 17:10:52 +0200

Hi,

>Right, just Chuck Norris can do that.

Good old Chuck is too cool for any of this :)

>question is: should this draft cover such posibility? or should it

If it's SIP stateful, how can it not be a SIP device?

What is your definition of SIP device?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 17:26:11 +0200

> If it's SIP stateful, how can it not be a SIP device?

It's not SIP stateful (I understand SIP transaction stateful). It's
just a layer 3 router but implements ugly SIP ALG to replace private
IP's with public IP, just it. But let's suppose that in the case of
MSRP it does it "well" (according to CEMA spec).

> What is your definition of SIP device?

Something that listens in a port at application level and is reachable
at application level (SIP protocol). A SIP ALG router will never
generate a SIP response or request, it just forwards requests and
responses and apply painful IP substitution to the whole
message/headers.

Just to clarify: I'm speaking about cheap routers implementing SIP ALG
feature, like most in this list:
  http://www.voip-info.org/wiki/view/Routers+SIP+ALG

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 19:24:57 +0200

Hi,

>http://www.voip-info.org/wiki/view/Routers+SIP+ALG

It's difficult for me to understand how such devices would be able to modify SDP, Call-ID etc in a consistant way throughout the session, without maintaining SIP state...

Anyway, the intention of the definition text was to avoid having these kind of discussions. So, what if we only use "device", then? Again, what is relevant is the fact that it anchors media - not what else it does or doesn't do.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 15 Jun 2011 19:32:55 +0200

> It's difficult for me to understand how such devices would be able to modify SDP, Call-ID etc in a consistant way throughout the session, without maintaining SIP state...

As ridiculous as it sounds they use regular expressions the sip message and keep no state.

As is clear text protocol and the developer has no clue about SIP protocol or a state machine, he spends his 4 hours budget on solving the problem like this.

We know it happened with SIP. So the question is how to completely discourage this initiatives when it comes to MSRP. 

Because this is what this draft would stimulates indirectly, though not the intention of the authors.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 19:39:05 +0200

Hi,

>Because this is what this draft would stimulates indirectly, though not the intention of the authors.

Keep in mind that the device we are talking about needs to enable MSRP B2BUA functionality in some cases, and that requires more than modifying SIP/SDP information. We also make other ALG assumptions, as described in section 5.

I don't think the type of device mentioned by Iñaki would "fit" into that definition :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 19:47:59 +0200

> It's difficult for me to understand how such devices would be able to modify SDP, Call-ID etc in a consistant way throughout the session, without maintaining SIP state...

Christer, don't take me wrong, but your comment scares me. Could you
please visit the real world and contract any commercial ADSL with any
Internet provider for residential market in any country of the world?
: )

*All* the Internet routers (home internet routers, yes, but homes do
exist in the world) I've tested come with SIP ALG built-in and enabled
by default, and *all* of them break SIP signalling (and the worst,
some of them don't allow dissabling SIP ALG).

So, if people like you making such kind of specifications are not
aware of the real problems of VoIP in the real world, should we expect
that the history will be repeated for any new protocol (i.e. MSRP)?

Please don't take me wrong. Regards.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jun 2011 13:50:37 -0400

How about...

Middlebox: Within the scope of this document, "Middlebox" refers to a SIP entity between the UAC and ultimate UAS, that modifies SDP media address:port information in
order to relay (anchor) media flows described in the SDP, including TCP connections used for MSRP communication, through a media proxy function controlled by the Middlebox. Unlike an RFC 4976 MSRP Relay, a Middlebox does not modify MSRP headers nor process MSRP messages at the application layer, but rather operates at the IP and transport layers only.  Other SIP related functions (e.g. related to routing, modification of SIP information, etc.) performed by the Middlebox, and whether it is a SIP B2BUA or not, is outside the scope of the definition. Section 5 describes assumptions regarding how the Middlebox handles MSRP in order to support the extension defined in this document.

On Jun 15, 2011, at 7:53 AM, Christer Holmberg wrote:

Hi,

------------

------------

Regards,

Christer

<ATT00001..c>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 19:48:49 +0200

Hi,

>Internet provider for residential market in any country of the world?

Trust me - I know what stuff exists out there :)

My issue is how these kind of entities would be able to support CEMA. For example, I don't think they are able to enable MSRP B2BUA functionality, which the draft assumes an ALG is able to.

So, therefor I don't think they are within the scope of the CEMA definition of ALG.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jun 2011 13:55:26 -0400

> The purpose of the definition text was that we don't need to have general discussions about what types of nodes are included or excluded, or that the name we use means something else. We now say wh…

Sure, but if our definition goes against common industry parlance, then it's not useful.  An "ALG" really does denote something already, and given the confusion on this mailing list I think it would be safer not to use the term.

> And, the only thing we care about is that they anchor MSRP media, as described in the definition text.

Well... ALGs don't actually "anchor" MSRP or media the same way as "normal" SIP B2BUAs do.  For example, they modify the SDP and the IP/transport in one direction but not the other.  Thus even on the wire you'd see a difference.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 19:56:48 +0200

Hi,

>>The purpose of the definition text was that we don't need to have general discussions about what types of 
>>nodes are included or excluded, or that the name we use means something else. We now say what we mean 
>>by ALG within the scope of sessmatch.
>
>Sure, but if our definition goes against common industry parlance, then it's not useful.  An "ALG" really does >denote something already, and given the confusion on this mailing list I think it would be safer not to use the >term.

No problem, we can use whatever term :)

At this point I was more focusing on the actual definition text.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 20:00:28 +0200

> My issue is how these kind of entities would be able to support CEMA. For example, I don't think they are able to enable MSRP B2BUA functionality, which the draft assumes an ALG is able to.

No, Dragon-IP-Net or Chiun-Chiun-Tech-IP vendors will indeed not
include MSRP B2BUA funcionality in their home routers. But they *will*
do ugly replacements in SIP traffic within their routers (so they can
announce a "SIP enchanded" label or "Works with SIP").

If CEMA let such vendors doing it in a way that, at least, could work,
then maybe they decide to implement it instead of performing a global
regex substitution in the whole SIP message as they do now.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 20:11:59 +0200

Hi,

>announce a "SIP enchanded" label or "Works with SIP").

Yes, but they are already doing it today, and they will continue to do it. It has nothing to do with CEMA. They will probably not even read the CEMA spec :)

>regex substitution in the whole SIP message as they do now.

I don't understand what you mean by "let such vendors doing". CEMA assumes that the devices can enable MSRP B2BUA functionality. If they don't, they will break things in the same way as they already do...

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 20:16:16 +0200

> I don't understand what you mean by "let such vendors doing". CEMA assumes that the devices can enable MSRP B2BUA functionality. If they don't, they will break things in the same way as they alread…

Right. But there is however the case in which the MSRP endpoint behind
NAT suports CEMA, and the SIP ALG NAT router (not a SIP entity)
performs SDP modification as CEMA states. Then MSRP could work.

But if the SIP ALG NAT router just performs a whole IP substitution in
the SIP message then it will break MSRP, for sure.

Anyhow, maybe it's just better to ignore SIP ALG routers ;)

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Jun 2011 20:18:59 +0200

Hi Hadriel,

As I said in another reply, I have no problem to call the device "Middlebox", if it's less confusing :)

However, your proposed text does not cover the case when the device enables MSRP B2BUA functionality.

Middlebox:    Within the scope of this document, Middlebox refers to a network SIP device that modifies SDP media address:port information in
order to steer (anchor) media flows described in the SDP, including TCP connections used for MSRP communication, through a
media proxy function controlled by the SIP device. In most cases the media proxy function relays the MSRP messages without modification, while
in other cases it enables MSRP B2BUA functionality. Other SIP related functions (e.g. related to routing, modification of SIP information
etc) performed by the SIP device, and whether it acts a SIP B2BUA or not, is outside the scope of the definition. Section 5 describes additional
assumptions regarding how the Middlebox handles MSRP in order to support the extension defined in this document.

Regards,

Christer

________________________________
From: Hadriel Kaplan [[email-masked]]
Sent: Wednesday, June 15, 2011 8:50 PM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [Simple] CEMA: ALG definition proposal

How about...

Hi,

------------

------------

Regards,

Christer

<ATT00001..c>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jun 2011 20:28:06 +0200

2011/6/15 Hadriel Kaplan <[email-masked]>:
> How about...
>
> Middlebox: Within the scope of this document, "Middlebox" refers to a SIP
> entity between the UAC and ultimate UAS, that modifies SDP media
> address:port information in
> order to relay (anchor) media flows described in the SDP, including TCP
> connections used for MSRP communication, through a media proxy function
> controlled by the Middlebox. Unlike an RFC 4976 MSRP Relay, a Middlebox does
> not modify MSRP headers nor process MSRP messages at the application layer,
> but rather operates at the IP and transport layers only.  Other SIP related
> functions (e.g. related to routing, modification of SIP information, etc.)
> performed by the Middlebox, and whether it is a SIP B2BUA or not, is outside
> the scope of the definition. Section 5 describes assumptions regarding how
> the Middlebox handles MSRP in order to support the extension defined in this
> document.

I understand it, no doubts after reading it. I like it.

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