Subject: RE: [Ieprep] a little homily - benefits of multicast

From: "Gibson, Mark" <[email-masked]>
Date: Thu, 4 Apr 2002 10:40:16 +0100

You might also wish to cast you eyes over the appendix section of the
referenced and now expired draft. While more global in scope, it captures
the
issues nicely. 

http://alternic.net/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.txt

Mark

meant to send this to the list, sorry you got two copies Ken :(

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: 03 April 2002 16:40
To: Dean Bogdanovic
Cc: [email-masked]
Subject: Re: [Ieprep] a little homily - benefits of multicast

> And the last one is voice quality perception. What you or me accept as
> OK, other people might not.

see the following for a couple of perspectives on user tolerance of 
loss/delay for VoIP traffic.

  http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip
  http://www.cs.ucl.ac.uk/staff/A.Sasse/inet95audio.ps

the above does not provide a definitive answer, just some insights.
and as previously stated, your mileage may very depending on the Codec 
in use.

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Scott Bradner <[email-masked]>
Date: Thu, 4 Apr 2002 12:51:35 -0500 (EST)

> I don't see why innovators can't be left to implement new applications for
> closed emergency service networks, using multicast or not.

I fully support this - I just do not think that things are ready
for this working group to make any statements about the use of 
multicast (or to ask for an allocation of multicast addresses)

Scott

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Apr 2002 09:17:23 -0500

Yes, SIP can negotiate codecs.  One end "offers" it's list of
codecs, the other end "answers" with its choice(s).
Transcoders are at present uncommon, and we might want to
get some work done in SIP to make it a little more standardized
how transcoders might be discovered and engaged. 

Brian

> From: Alistair Munro [mailto:[email-masked]]
> Sent: Friday, April 05, 2002 7:58 AM
> To: Ken Carlberg
> Cc: [email-masked]
> Hi Ken,
> >I have an open ear to adding text to the current draft on 
> subjects it 
> >doesn't cover, but i'll take a very cautious approach 
> regarding codecs
> >because i have the (possibly mis)conception that the subject really
> >gets rather implementation/deployment specific.
> >
> Yes, I would leave people to make their own decisions on 
> implementation, 
> deployment etc.
> 
> I was wondering if there were any issues in the interworking of 
> different operational networks, but decided that protocols exist to 
> arbitrate the selection of codecs (does SIP do this? my H.323 setup 
> seems happy to switch) and transcoding at boundaries is (a) done, (b) 
> not an issue for this WG, except possibly to remark on QoS 
> and bandwidth 
> allocation. Any comments on this will apply to video and voice.
> 
> Regards,
> 
> Alistair
> 
> -- 
> Dr. Alistair Munro,
> Chief Systems Engineer, Degree2 Innovations Ltd.
> Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
> E-mail: [email-masked]
> Tel: (work) +44-117-900-8114, (home) +44-1275-462707, 
> (mobile) +44-7974-922-442;
> Fax: +44-117-900-8151
> Web: http://www.degree2.com, http://www.u4eagroup.com
> 
> 
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 17 Apr 2002 09:21:30 -0500

At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote:

>Transcoders are at present uncommon, 

huh? We build several products that do this function by design -- and have for
more than 2 (3?) years

>and we might want to

I would agree with this statement, but this is more a function of a Server in
the route maybe causing a redirect to a known transcoder (like a conference) of
that Server 
*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 17 Apr 2002 11:18:12 -0500

At 11:09 AM 4/17/2002 -0400, Rosen, Brian wrote: 
>
> Are we talking about  the same thing?

yep

>
>  
> A transcoder would be a box on the net that took a stream with one codec in
> and put a stream
> with another codec out.   

that's the definition I know

>
> So, perhaps you would have a box 

several actually

>
> that would do G.729 to G.711
> transcoding so that a phone that did not have a G.729 codec could talk to a
> phone that
> did, 

for many many (blue) moons

>
> but refused to allow a G.711 call.  

this last part-sentence i don't follow, why would you refuse the G.711 call in
the above scenario?

And we current can't go G.7XX to GSM. It's a combination of G.711, G.723 and
G.729 only for now

>
> In SIP terms, this would be a B2BUA in most cases.

Again -- I agree we need to work on how to find the Transcoder within the
session set-up, and then what it can and cannot do (signal and insert headers
types of things).

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems