Howdy,
I read the draft, and also found the use of the term "ALG" to be confusing and annoying.  It's not just rfc3303 which defines an ALG as being in a inline/NAT type device - lots of the user market uses the term ALG for inline type as well. (it's basically a derogatory term)  One "SBC" vendor I know of arguably had a real SIP ALG, but they went defunct years ago.

Then again, the drawings actually show the SIP-ALG+middlebox not changing the SDP at all, so maybe they do mean ALG.

But anyway... I don't mean to sound negative, but what's the purpose of this document?  What do we think it's going to achieve if it's published as an RFC?
The only "output" of this document are four "preliminary recommendations".  Of those four, I'd argue three of them are now wrong or misleading, and the remaining one is unlikely to occur/help.  It also claims to describe the impact on ICE, but doesn't; claims to propose mechanisms to mitigate latching, but doesn't; doesn't describe the issues with middleboxes and forked or moved calls on early in-band media signaling; and uses terminology from ancient history (ie, RFC 3303).

So what's the point of this doc again?

-hadriel



On Mar 31, 2011, at 10:13 AM, Dan Wing wrote:

>> -----Original Message-----
>> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]
>> Sent: Thursday, March 31, 2011 1:01 PM
>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith);
>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic
>> Subject: RE: [MMUSIC] Continued WG interest in SDP
>> offer/answerwithmiddleboxes?
>>
>> I agree with your interpretation of what an SBC is. However, the reason
>> why I don't find anything wrong in the use of ALG in
>> draft-ietf-mmusic-media-path-middleboxes is because it describes
>> firewall and NAT traversal functions that are typically implemented as
>> ALGs, except that these functions are decoupled into a MIDCOM agent and
>> a middle box. In addition RFC 3303 goes on to say (section 2.8) that
>> MIDCOM agents are entities performing ALG functions, logically external
>> to a middlebox. It even says these agents can reside on a proxy.
>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the ALG
>> in
>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the draft
>> I think.
>
> If Figure 1 was modified to show a NAT or firewall, it could reasonably
> use the term ALG with those devices.
>
> But when showing an SBC, which is smack in the middle of Figure 1,
> it cannot accurately call the SBC a "SIP ALG", as it does right now.
>
> -d
>
>
>> Muthu
>>
>> |-----Original Message-----
>> |From: Dan Wing (dwing)
>> |Sent: Wednesday, March 30, 2011 2:52 PM
>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr);
>> 'DRAGE, Keith (Keith)'; 'Christer
>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic'
>> |Subject: RE: [MMUSIC] Continued WG interest in SDP
>> offer/answerwithmiddleboxes?
>> |
>> |> -----Original Message-----
>> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]
>> |> Sent: Tuesday, March 29, 2011 3:58 PM
>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer
>> Holmberg;
>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic
>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP
>> |> offer/answerwithmiddleboxes?
>> |>
>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes is just
>> an
>> |> extension of RFC 3303 -- while the later describes the middlebox
>> |> communication architecture and framework, the former describes some
>> of
>> |> the desirable behaviors of these middleboxes and protocols that
>> operate
>> |> on the media path unspecified in the later.  RFC 3303 defines what
>> an
>> |> ALG is and it doesn't forbid packets being addressed to the ALG at
>> the
>> |> IP layer.
>> |>
>> |> <snip>
>> |> 2.6. ALG
>> |> Application Level Gateways (ALGs) are entities that possess the
>> |> application specific intelligence and knowledge of an associated
>> |> middlebox function.  An ALG examines application traffic in transit
>> |> and assists the middlebox in carrying out its function.
>> |>
>> |> ALGs are different from proxies.  ALGs are not visible to end-hosts,
>> |> unlike the proxies which are relay agents terminating sessions with
>> |> both end-hosts.  ALGs do not terminate sessions with either end-
>> host.
>> |> Instead, ALGs examine, and optionally modify, application payload
>> |> content to facilitate the flow of application traffic through a
>> |> middlebox.
>> |>
>> |> 2.8. MIDCOM Agents
>> |> MIDCOM agents are entities performing ALG functions, logically
>> |> external to a middlebox.
>> |>
>> |> The packets may be addressed to the agent node at the IP layer.
>> |> Alternatively they may not be addressed to the agent node, but may
>> be
>> |> constrained by other factors to flow through it.
>> |> </snip>
>> |>
>> |> So, I don't see anything wrong in the use of ALG in
>> |> draft-ietf-mmusic-media-path-middleboxes, unless we plan to make
>> |> changes
>> |> to how RFC 3303 describes it.
>> |
>> |3303 is quite clear, in exactly the text you quoted in the paragraph
>> |starting with "ALGs are different from proxies", that ALGs aren't
>> |visible to hosts and ALGs don't terminate sessions.
>> |
>> |An SBC is certainly visible to the end host, for both the SIP
>> |signaling and the RTP media -- the end host is sending packets
>> |to the SBC's IP address and receiving packets from the SBC's
>> |IP address.
>> |
>> |-d
>> |
>> |
>> |> Muthu
>> |>
>> |> |-----Original Message-----
>> |> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> |> Behalf Of Parthasarathi R (partr)
>> |> |Sent: Wednesday, March 16, 2011 6:15 PM
>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing (dwing);
>> |> Flemming
>> |> Andreasen (fandreas); mmusic
>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP
>> |> offer/answerwithmiddleboxes?
>> |> |
>> |> |Keith,
>> |> |
>> |> |Sorry in case "media" word in my mail mislead you. Dan explains in
>> |> |another mail thread
>> |> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html)
>> |> why
>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for this
>> |> draft.
>> |> |
>> |> |
>> |> |Fig 1 of draft-ietf-mmusic-media-path-middleboxes-03.txt exactly
>> fits
>> |> |your definition of B2BUA as it involves only SIP & SDP and media is
>> |> |defined as middlebox.
>> |> |
>> |> |I have mentioned as kind of B2BUA because the draft concentrates on
>> |> |callflow where one side of B2BUA acts as UAC and other side always
>> |> acts
>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC
>> callflows
>> |> |specific issues. In the current scope of draft is continued for the
>> |> |draft, the new definition may be required or draft text has to
>> clarify
>> |> |the scope.
>> |> |
>> |> |Thanks
>> |> |Partha
>> |> |
>> |> |-----Original Message-----
>> |> |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
>> |> |Sent: Wednesday, March 16, 2011 5:33 PM
>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing (dwing);
>> |> |Flemming Andreasen (fandreas); mmusic
>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer
>> |> |withmiddleboxes?
>> |> |
>> |> |The only definition of B2BUA that I know of comes in RFC 3261 (sort
>> |> of)
>> |> |where the scope is limited to SIP. So a UA acts in one or more
>> |> |directions as a SIP UA. Whatever else it does is outside the
>> |> definition.
>> |> |That I believe matches with what Christer is saying.
>> |> |
>> |> |If you want something that defines what it does with media, then
>> you
>> |> |need something that defines that, but using the term B2BUA to do
>> that
>> |> is
>> |> |probably not the best choice.
>> |> |
>> |> |Regards
>> |> |
>> |> |Keith
>> |> |
>> |> |> -----Original Message-----
>> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> |> |> Behalf Of Parthasarathi R (partr)
>> |> |> Sent: 15 March 2011 09:54
>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen
>> |> |> (fandreas); mmusic
>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer
>> with
>> |> |> middleboxes?
>> |> |>
>> |> |> Christer,
>> |> |>
>> |> |> AFAIK, There is no restriction in terms of SIP B2BUA to handle
>> |> |> signaling only and it is upto the implementation to decide. Also,
>> |> this
>> |> |
>> |> |> draft does not have restriction that SIP B2BUA and media server
>> has
>> |> to
>> |> |
>> |> |> be co-exist in the same device. The draft talks about the
>> scenario
>> |> |> wherein SIP B2BUA communicates with media server using Megaco
>> |> (H.248).
>> |> |>
>> |> |> As I mentioned in other mail thread, ALG does not look
>> appropriate
>> |> and
>> |> |
>> |> |> the draft is talking only about the specific type of B2BUA. In
>> real
>> |> |> deployment, Few vendors named these sort of B2BUA as "Session
>> Border
>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as SBC
>> does
>> |> |> lot more. In case there is a need to have different name for
>> these
>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us work it
>> out.
>> |> |>
>> |> |> Thanks
>> |> |> Partha
>> |> |>
>> |> |> -----Original Message-----
>> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> |> |> Behalf Of Christer Holmberg
>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM
>> |> |> To: Dan Wing (dwing); Flemming Andreasen (fandreas); 'mmusic'
>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer
>> with
>> |> |> middleboxes?
>> |> |>
>> |> |>
>> |> |> Hi Dan,
>> |> |>
>> |> |> In my definition of an ALG packets can be sent directly to its IP
>> |> |> address.
>> |> |>
>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG also
>> |> |> focuses on other things, like media. A SIP ALG contains a SIP
>> B2BUA.
>> |> |>
>> |> |> Regards,
>> |> |>
>> |> |> Christer
>> |> |>
>> |> |> -----Original Message-----
>> |> |> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> |> |> Behalf Of Dan Wing
>> |> |> Sent: 15. maaliskuuta 2011 4:39
>> |> |> To: 'Flemming Andreasen'; 'mmusic'
>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer
>> with
>> |> |> middleboxes ?
>> |> |>
>> |> |> The draft uses the term "SIP ALG", which at least does not fit my
>> |> |> definition of an ALG.  An ALG doesn't have packets sent directly
>> to
>> |> |> its IP address; it does its job stealthily without awareness of
>> one
>> |> |> (or
>> |> |> both) of the sessoin endpoints.  In contrast, the function
>> described
>> |> |> in draft-ietf-mmusic-media-path-middleboxes
>> |> |> is different -- packets are always sent to the IP address of the
>> SIP
>> |> |> "ALG", and packets are sent from the IP address of the SIP "ALG".
>> |> |> This functionality is most often called a "server"
>> |> |> or a "proxy" -- not an ALG.
>> |> |>
>> |> |> This distinction is important because this draft is closely
>> related
>> |> to
>> |> |
>> |> |> functions common in NATs, which _do_ sometimes have SIP ALGs
>> |> |> implemented in them.
>> |> |>
>> |> |> So ... can we change "SIP ALG" to something like "SIP proxy"
>> |> |> or "SIP user agent" or "SIP Back-to-Back User Agent"?  Really, it
>> is
>> |> a
>> |> |
>> |> |> B2BUA, at least as best I understand the definition of a B2BUA,
>> so
>> |> |> B2BUA seems best.
>> |> |>
>> |> |> d
>> |> |>
>> |> |>
>> |> |> > -----Original Message-----
>> |> |> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
>> On
>> |> |> > Behalf Of Flemming Andreasen
>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM
>> |> |> > To: mmusic
>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP offer/answer
>> with
>> |> |> > middleboxes ?
>> |> |> >
>> |> |> > We currently have a MMUSIC milestone for "considerations for
>> using
>> |> |> > SDP
>> |> |>
>> |> |> > offer/answer with middleboxes". The latest draft for this WG
>> item
>> |> is
>> |> |> >
>> |> |> >      draft-ietf-mmusic-media-path-middleboxes-03.txt
>> |> |> >
>> |> |> > which expired in January 2011. There hasn't been much
>> discussion
>> |> on
>> |> |> > this topic for a while, and the current draft authors are not
>> |> |> > planning
>> |> |>
>> |> |> > continued work on the draft, so we need new authors if we are
>> to
>> |> |> > continue with this WG item. Please let us know if
>> |> |> > 1) You are still interested in this deliverable
>> |> |> > 2) You are willing to actively contribute to and/or author this
>> |> |> > document.
>> |> |> >
>> |> |> > Thanks
>> |> |> >
>> |> |> >          Flemming & Miguel [MMUSIC chairs]
>> |> |> >
>> |> |> >
>> |> |> > _______________________________________________
>> |> |> > mmusic mailing list
>> |> |> > mmusic@ietf.org
>> |> |> > https://www.ietf.org/mailman/listinfo/mmusic
>> |> |>
>> |> |> _______________________________________________
>> |> |> mmusic mailing list
>> |> |> mmusic@ietf.org
>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
>> |> |> _______________________________________________
>> |> |> mmusic mailing list
>> |> |> mmusic@ietf.org
>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
>> |> |> _______________________________________________
>> |> |> mmusic mailing list
>> |> |> mmusic@ietf.org
>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
>> |> |_______________________________________________
>> |> |mmusic mailing list
>> |> |mmusic@ietf.org
>> |> |https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic