Subject: RE: data issue 4: capacity

From: "Hutton, Charles" <[email-masked]>
Date: Fri, 26 Mar 1999 19:27:40 -0800

I think the implication here is that tandeming (transcoding) of codecs would
/ could be performed in AD4 and AD5. Unacceptable voice quality will quickly
result with G.723.1 and G.729 if they are tandemed; subjective measurements
show noticeable degradation with 1 tandeming and by 3 tandemings it is a
struggle to understand completely.

Also I would think that the audio coding format would be a don't-care to AD4
and AD5.

In summary (and hoping I have not misunderstood):

    - we can not tandem in every AD used in a call
    - and luckily, we have no reason to tandem in each AD

> Hussein F. Salama wrote:
> > 
> > > Most of the services you are talking about don't require the media to
> > > flow through the LS. Certainly control over capability negotiation
> does
> > > not (in H.323, gatekeeper routed H.245 is sufficient for this, and in
> > > SIP a proxy could rewrite SDP if it felt it needed to, for some
> reason),
> > > same with policy, security, accounting, and billing.
> > 
> > You're missing my point. Assume call signaling goes through an ingress
> > gateway in AD1, an intermediate signaling only proxy in AD2, and an
> > egress gateway in AD3. However, the media streams for that call do not
> > pass through AD2 at all. Assume the follow the path AD1-AD4-AD5-AD3.
> > Let's use H.323 as an example. The gatekeeper in AD1 may be interested
> > in controlling the capabilities because the ingress gateway is in its
> > domain and the media streams flow through that domain. Same thing
> > applies to the gatekeeper in the egress domain, AD3. But why would a
> > gatekeeper in AD2 care for being involved in, and routing this call? I
> > know it can, be I don't think it care. Since the layer 3 route doesn't
> > go through AD2.
> 
> A gatekeeper in AD2 would be interested since GLP effectively introduces
> a "subcontracting relationship" among the various providers. AD1 allows
> AD2 to use its gateways. By propagating this information to AD3, AD2 can
> appear to be its own gateway provider, when in fact its using gateways
> from AD1 to provide a more complete service. So, AD2 may want to see the
> signaling messages for call accounting purposes.
> 
> Same situation arises in building a house. One big contractor interfaces
> with you for the job, and they in turn subcontract some work out to
> other contactors, who may further subcontract that out. Invoices for
> work still pass through all of them, since they each provide the
> value-add of "aggregation of service".
> 
> > 
> > What if the gatekeepers in AD4 and AD5 want to control the capabilities
> > (codec selection) for  above call? I think it's their right to do that
> > since the voice streams will ultimately flow through their domains.
> > Would they be able to do that? Not when separating signaling from media.
> 
> Well, this has not happened yet at all for any other IP application.
> When I browse a web page, a hit a server in some domain AD1. I'm in AD2,
> and I have a local proxy. The actual traffic flows through many
> intermediate transit providers. To date, these providers have had no say
> in whether I download the text or glitzy-image version of a page, or
> whether I use gif or jpeg images. 
> 
> I do believe that an ISP should have control over what data leaves and
> enters its network, but that this functionality lives at layer 3.
> Diffserv and other things are how you control this. What you are
> proposing requires us to overlay an independent network of proxies and
> servers for every single application. One of the fundamental engineering
> assumptions in the Internet is that it is application unaware, and that
> apps live in the end systems. It is this model that has allowed new apps
> (like the web) to come into being.
> 
> > 
> > The same applies for accounting. What if the gatekeepers in AD4 and AD5
> > want to do accounting for  above call? I think it's their right to
> > account for voice traffic traversing their domain. Would they be able to
> > do that?
> 
> Accounting would be done in border routers (i.e., layer 3), using the
> diffserv model. The voice traffic (or any other high priority, delay
> sensitive traffic) would be marked at the ingress domain. Each border
> router could account for the amount of this kind of traffic, and then
> remark. So, you get the kind of accounting you want, but at layer 3.
> 
> > 
> > > QoS for the media
> > > is handled by things like rsvp and diffserv, not the call signaling in
> > > any case.
> > 
> > What if different intermediate domains on the media path of a call want
> > to provide different levels of QoS to same media stream? Let's use
> > RSVP/Intserv as an example. What if AD4 wants to provide controlled load
> > service for the audio streams while AD5 prefers to provide guaranteed
> > QoS?
> 
> So, let them do it. Normally RSVP is used to ask for only one of the
> two, but if for some reason a domain wanted to do something different,
> it could perhaps rewrite the RSVP messages at the border routers, or
> something like that. Certainly one domain can do diffserv, and another
> rsvp. Check out draft-ietf-diffserv-rsvp. In either case, gatekeepers
> and sip servers are not involved.
> 
> 
> > 
> > > For both gatekeeper routed signaling in H.323, and proxy
> > > invite's in SIP, the media flows regularly between endpoints, not
> > > through the gatekeepers or sip servers. Yet, people seem to be able to
> > > bill, account, maintain control, etc.
> > 
> > See my above comment on accounting. So far people are doing accounting,
> > billing, ... etc at the ingress and egress domains only. This will
> > change as the volume of VoIP traffic increases.
> 
> I agree we need accounting for voice traffic in intermediate domains.
> Thats with diffserv border routers are for.
> 
> > > I'm not so sure. We had lengthy discussions on this list regarding
> > > directory services for GLP. It doesn't work. Many gateways can service
> a
> > > particular number; the right one to use depends on the agreements
> > > between providers. This kind of environment cannot be supported in a
> > > global directory solution, like DNS. Your alternative, a single hop
> call
> > > routing protocol, doesn't scale all that well. It would require
> gateway
> > > providers to all have bilateral agreements with each other. Would you
> > > advocate regular IP routing protocols that support only one hop?
> > 
> > I didn't use "single hop call routing" in the right context.What I meant
> > "single hop inter domain call signaling." This can be done using either
> > the BGP-based GLP proposal or the SCSP-based proposal, and never
> > changing the NEXT_HOP attribute when an update is propagated from one
> > domain to another. The NEXT_HOP will always point directly to the egress
> > domain.
> 
> I see, sorry for my misunderstanding. I think I address your point
> already above. Intermediate LS's may want to be on the signaling path
> for accounting (call usage, mind you, not voice level accounting). If
> they don't want this, then you are correct. Single-hop signaling is just
> fine. As I said, we have a perfectly nice underlying transport network
> that allows us to go from anywhere to anywhere else.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: [email-masked]
> URL: http://www.cs.columbia.edu/~jdrosen
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
> 

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Hussein F Salama <[email-masked]>
Date: Sat, 27 Mar 1999 23:37:07 -0800

Charles,

I agree with you, doing multiple transcodings is bad. Howerver,
tandemiing does not imply transcoding.

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC-6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: (408) 527 7147, Fax: (408) 527 1714

---------