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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 17 Apr 2002 11:09:32 -0400

Are we talking about  the same thing?
 
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.   So, perhaps you would have a box 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, but refused to allow a G.711 call.  In SIP terms, this would be a B2BUA
in most cases.
 
It would not include transcode functions that were part of a bridge, so that
each participant
could choose which codec it presented to the bridge.  It wouldn't include
transcodes that
are part of  a gateway (so you could take a G.729 call from a SIP phone and
transcode
it to a GSM codec for example).  I'm differentiating these cases because at
present we
don't have standardized ways of locating transcoders or engaging them in SIP
calls.
For example, would it be the UA that decides it can't agree on a common
codec
with the other UA and engage the transcoder, or does a proxy server do that?
How do you format the SIP message to the transcoder (if it is a B2BUA) so
that it
does the right thing?   'Standards' in this case is more appropriately "best
practice'
but since it involves at least 2 and possibly three elements, we need some
agreement
on how it's used.
 
AFAIK transcoders as stand alone boxes are still uncommon, but they are
functions that media
servers are bringing out, so I would expect them to be more common in the
future.
 
Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 10:22 AM
To: Rosen, Brian; 'Alistair Munro'; Ken Carlberg
Cc: [email-masked]
Subject: RE: [Ieprep] a little homily - benefits of multicast

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
>get some work done in SIP to make it a little more standardized
>how transcoders might be discovered and engaged. 

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 <http://www.cisco.com/>

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 17 Apr 2002 23:17:58 -0400

>does the right thing? 

Well we always have to persume that UAs have to be able to agree on
common codec, because parts of the infratstructure can be
nonoperational in emergency situation, so transcoder and proxy might
not be available or the network distance might be unacceptable from
quality perspective. And as I understood one of the goals of this WG is
to come up with BCP, so we can propose cases what steps to take in
order to prevent such failures which could stop communications. 
I know that the protocol groups have to know how to format headers,
but they have to start from worst case scenario and minimum
operational network. The beauty of SIP is that is decentralized and UA
can comunicate directly without third nodes beeing involved. Lets try
to pursue that model for ECS as much as possible.

--br

Dean
>------_=_NextPart_001_01C1E621.E0D18020
>Content-Type: text/html;
>	charset="ISO-8859-1"
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML><HEAD>
><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
>
>
><META content="MSHTML 6.00.2712.300" name=GENERATOR></HEAD>
><BODY>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>Are we 
>talking about&nbsp; the same thing?</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial 
>color=#0000ff></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>A transcode
r 
>would be a box on the net that took a stream with one codec in and put a 
>stream</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>with anothe
r 
>codec out.&nbsp;&nbsp; So, perhaps you would have a box that would do G.729 to
 
>G.711</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>transcoding
 
>so that a phone that did not have a G.729 codec could talk to a phone 
>that</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>did, but 
>refused to allow a G.711 call.&nbsp; In SIP terms, this would be a B2BUA in mo
st 
>cases.</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial 
>color=#0000ff></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>It would no
t 
>include transcode functions that were part of a bridge, so that each 
>participant</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>could choos
e 
>which codec it presented to the bridge.&nbsp; It wouldn't include transcodes 
>that</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>are part 
>of&nbsp; a gateway (so you could take a G.729 call from a SIP phone and 
>transcode</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>it to a GSM
 
>codec for example).&nbsp; I'm differentiating these cases because at present 
>we</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>don't have 
>standardized ways of locating transcoders or engaging them in SIP 
>calls.</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>For example
, 
>would it be the UA that decides it can't agree on a common 
>codec</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>with the 
>other UA and engage the transcoder, or does a proxy server do 
>that?</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>How do you 
>format the SIP message to the transcoder (if it is a B2BUA) so that 
>it</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>does the 
>right thing?&nbsp;&nbsp; 'Standards' in this case is more appropriately "best 
>practice'</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>but since i
t 
>involves at least 2 and possibly three elements, we need some 
>agreement</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>on how it's
 
>used.</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial 
>color=#0000ff></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>AFAIK 
>transcoders as stand alone boxes are still uncommon, but they are functions th
at 
>media</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial color=#0000ff>servers are
 
>bringing out, so I would expect them to be more common in the 
>future.</FONT></SPAN></DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial 
>color=#0000ff></FONT></SPAN>&nbsp;</DIV>
><DIV><SPAN class=419265414-17042002><FONT face=Arial 
>color=#0000ff>Brian</FONT></SPAN></DIV>
><BLOCKQUOTE 
>style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
>  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
>  size=2>-----Original Message-----<BR><B>From:</B> James M. Polk 
>  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, April 17, 2002 10:22 
>  AM<BR><B>To:</B> Rosen, Brian; 'Alistair Munro'; Ken Carlberg<BR><B>Cc:</B> 
>  [email-masked]<BR><B>Subject:</B> RE: [Ieprep] a little homily - benefits o
f 
>  multicast<BR><BR></FONT></DIV>
>  <DIV>At 09:17 AM 4/5/2002 -0500, Rosen, Brian wrote:</DIV><BR>
>  <DIV>&gt;Transcoders are at present uncommon, </DIV><BR>
>  <DIV>huh? We build several products that do this function by design -- and 
>  have for more than 2 (3?) years</DIV><BR>
>  <DIV>&gt;and we might want to</DIV>
>  <DIV>&gt;get some work done in SIP to make it a little more standardized</DI
V>
>  <DIV>&gt;how transcoders might be discovered and engaged. </DIV><BR>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 <BR>
>  <DIV align=center>*************************************<BR>"People generally
 
>  demand more respect for their own rights than they are willing to allow for 
>  others"<BR><BR></DIV>James M. Polk<BR>Consulting Engineer<BR>Office of the 
>  CTO<BR><BR>Cisco Systems<BR>2200 East President George Bush Turnpike 
>  <BR>Richardson, TX&nbsp; 75082 USA<BR>w) 972.813.5208<BR>f)&nbsp; 
>  972.813.5280<BR><A href="http://www.cisco.com/" 
>  eudora="autourl">www.cisco.com</A> </BLOCKQUOTE></BODY></HTML>
>
>------_=_NextPart_001_01C1E621.E0D18020--
>
>_______________________________________________
>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: Alistair Munro <[email-masked]>
Date: Thu, 18 Apr 2002 15:56:02 +0100

Hi All,

Sorry, I had to remove the "a little homily on multicast" from the 
subject as we have strayed a long way from that thread.

>to pursue that model for ECS as much as possible.
Decentralisation is essential to survive an emergency situation or 
attack - I think that this is a general principle. The Internet does it 
a network level - that's what it's for after all, and it's under attack 
all the time, mostly from itself by many accounts (extension of the 
immunity analogy Fred suggested for security?).

Applications must similarly be decentralised - which is less obvious but 
I'm sure we can write down what is done currently. For example for 
voice, where SIP will fit the requirement, emergency services use direct 
mode (their term) voice in an open channel (similar to rat/vat operating 
over multicast). This function comes for free with typical IP phones.

The transcoding issue seems orthogonal to the survivability issue. If it 
is necessary to use a proxy/server to do any 
forwarding/switching/interworking function then the application (by 
which I mean the aggregate of all the participating physical objects and 
their interconnect) should be configurable to adapt to failure of any 
single point, possibly more than a single point. As to preventing 
failure - attaining a desired bound on the likelihood of failure is 
planning, design and $ choice, not a requirement.

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