Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes?

["Belling, Thomas (NSN - DE/Munich)" <[e-mail]>]

For ICE: 3GPP terminates it as an SBC.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of ext Muthu ArulMozhi Perumal (mperumal)
Sent: Friday, April 01, 2011 2:12 PM
To: Christer Holmberg; Hadriel Kaplan; mmusic
Subject: Re: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?

Does 3GPP have similar issues in getting signaling protocols that
operate on the media path (ICE, DTLS etc) though their SBCs? Do they
have any recommendations to make them work better?

thanks,
Muthu 

|-----Original Message-----
|From: Christer Holmberg [mailto:[e-mail]]
|Sent: Friday, April 01, 2011 12:28 PM
|To: Muthu ArulMozhi Perumal (mperumal); Hadriel Kaplan; mmusic
|Subject: RE: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?
|
|Hi,
|
|>The main goal of the draft as it seems to claim is to describe the 
|>desirable behaviors of middleboxes and signaling protocols that 
|>operate on the media path, to aid in firewall/NAT traversal. It looks 
|>like an extension of RFC
|>3303 whose focus is also firewall and NAT traversal use-cases. The 
|>draft claims that the architecture/functions it describes is used in 
|>IMS and specified in 3GPP, TISPAN and PacketCable specs -- if it true,

|>then this is where the recommendations in the draft would be useful I 
|>think.
|
|3GPP already specifies NAT traversal etc behavior for their "SBCs".
|
|Regards,
|
|Christer
|
|> However, it doesn't look it would be useful for all B2BUA/SBC 
|> use-cases/deployments -- if we want to make it, then I think it would

|> be a scope creep.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [e-mail] [mailto:[e-mail]] On
|> Behalf Of Hadriel Kaplan
|> |Sent: Friday, April 01, 2011 5:42 AM
|> |To: mmusic
|> |Subject: Re: [MMUSIC] Continued WG interest inSDP
|> offer/answerwithmiddleboxes?
|> |
|> |
|> |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:[e-mail]]
|> |>> 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:[e-mail]]
|> |>> |> 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: [e-mail]
[mailto:[e-mail]]
|> 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:[e-mail]]
|> |>> |> |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: [e-mail]
|> [mailto:[e-mail]]
|> 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: [e-mail]
|> [mailto:[e-mail]]
|> 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: [e-mail]
|> [mailto:[e-mail]]
|> 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: [e-mail]
|> [mailto:[e-mail]]
|> |>> 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
|> |>> |> |> > [e-mail]
|> |>> |> |> > https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |>
|> |>> |> |> _______________________________________________
|> |>> |> |> mmusic mailing list
|> |>> |> |> [e-mail]
|> |>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |> _______________________________________________
|> |>> |> |> mmusic mailing list
|> |>> |> |> [e-mail]
|> |>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |> _______________________________________________
|> |>> |> |> mmusic mailing list
|> |>> |> |> [e-mail]
|> |>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |_______________________________________________
|> |>> |> |mmusic mailing list
|> |>> |> |[e-mail]
|> |>> |> |https://www.ietf.org/mailman/listinfo/mmusic
|> |>
|> |> _______________________________________________
|> |> mmusic mailing list
|> |> [e-mail]
|> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |
|> |_______________________________________________
|> |mmusic mailing list
|> |[e-mail]
|> |https://www.ietf.org/mailman/listinfo/mmusic
|> _______________________________________________
|> mmusic mailing list
|> [e-mail]
|> https://www.ietf.org/mailman/listinfo/mmusic
|>
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic