Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.)

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Jul 2001 10:59:43 -0400

I like almost all of what you are saying, but one part is
a little confusing.

If I have a SIP end point, and it's not a PSTN gateway, but
a sipphone, and it doesn't have a codec for whatever is
coming at it, you don't want the sipphone to know about
transcoders and Megaco do you?  You want some intermediate
proxy server to recognize the problem and DTRT.

I really do buy into the central argument that just because
the media stream is going through an extra device DOESN'T
mean the signalling has to.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 8:53 PM
> To: 'Michael Thomas'; [email-masked]
> Cc: 'Henning Schulzrinne'; [email-masked]; Paul Kyzivat;
> Jay Batson; [email-masked]
> Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest
> proposal.)
> 
> 
> > From: Michael Thomas [mailto:[email-masked]]
> > 
> > [email-masked] writes:
> >  > This is why (I feel) we need to come up with a good architecture
> >  > to support transcoding which doesn't require a B2BUA. No, I'm not
> >  > proposing a work item (we do protocols, not architectures); I'm
> >  > just thinking out loud.
> > 
> >    Well, stop it :-)
> > 
> >    I sense that what you're hoping for is the moral equivalent
> >    of an RTP NAT and to that I say TANSTAAFL. There's a variety
> >    of ways that you could implement and/or control your transcoder
> >    box, but let's not allow delusion to creep in here that what
> >    is finally shaked and baked isn't, in fact, a form of an
> >    application layer gateway, lest the curse of Deering be upon
> >    you :-)
> 
> Okay, now you've provoked me. :)
> 
> The fact that you would assume that the *signalling* needs to 
> go through
> some special box to allow transcoding just highlights how 
> entrenched the
> mindset that I'm railing against has become. This is a fallacy that no
> one seems to even question.
> 
> Allow me to clarify.
> 
> If we have network-provided transcoding, we'll need to send the RTP
> through some transcoder box. There are two ways to achieve this.
> 
> The trivial solution is to send the signaling through some transcoder
> control box; it acts as a B2BUA, in much the same way that a 
> conference
> bridge would. (This is extremely simple for terminals to do: 
> if you send
> me an INVITE for a codec I don't know, I send you a 305 
> response to tell
> you to go to my transcoder -- or, if I get a 488 or 606, I send a new
> invite through my transcoder).
> 
> Alternately, when a codec mismatch is detected, you can set up some
> relationship whereby the terminal communicates with a transcoder using
> an appropriate protocol (H.248 comes to mind) to pre-arrange the fact
> that media coming in to the transcoder on a negotiated port will be
> transcoded and sent to the terminal (and the same thing in the reverse
> direction).
> 
> Both approaches work, and one of them will *need* to be deployed. 
> 
> The former has all the drawbacks of a B2BUA combined with the 
> drawbacks of
> needing a transcoder in the network; the latter merely has 
> the drawbacks
> of having a transcoder. Unfortunately, most people seem to be leaning
> towards the first solution -- which is terrible, in my mind. 
> Just because
> we're having to use a transcoder should not mean that feature 
> transparency
> is destroyed. I'm trying to being attention to the fact that 
> using a B2BUA
> for this application is EVIL, and should be avoided when possible.
> 
> I agree that trying to put a "transparent" SIP proxy in the 
> path to munge
> the SDP is completely the wrong answer, and -- lest anyone be 
> confused --
> such a solution is absolutely nothing like what I was suggesting.
> 
> /a
> 
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Thu, 12 Jul 2001 17:13:44 -0500

It doesn't necessarily have to be Megaco. I just threw that
out as an example, since I think everyone here is familiar with
the basic operations it can perform.

I *do*, however, think that this is something that the endpoint
itself will initiate, for a variety of reasons:

- Without some really hokey provisioning going on, the node in the
  middle of the network won't know my terminal's capabilities; it
  cannot make the right decision.

- I (as an end-user) will possibly be charged for using these network
  transcoders. I can easily envision getting a call with my a special
  ring that means "this will be a slightly more expensive call
  since it will use a transcoder," and decide to reject or accept it
  based on that information combined with the identity of the calling
  party. I would like to be able to do this real-time by e.g. pressing
  "answer" or "reject" on my terminal, not based on some long-running
  policy provisioned into the handset and/or a server in the network.

- Anything in the middle of the network doing the "Right Thing" will
  be munging the SDP. This is a horrible hack: it breaks security
  models (my signed messages are suddenly tampered with!); it may
  necessarily remove attributes that my endpoint wanted to see; it
  will need upgrading when SDPng is deployed...

Given these arguments, all that is left is the question of *how*
the terminal brings the transcoder into the loop. On its face, it
needs to be able to say "take incoming media encoded by this codec
from this port, transcode it to a different codec, and send it to
a specific IP address at a particular port."

The list of protocols which are designed to say this sort of thing
is rather short. I'll leave it as an exercise for the readers of
this list to find any beyond those that have already been mentioned.

/a

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, July 12, 2001 10:00 AM
> To: [email-masked]'; 'Michael Thomas'
> proposa l.)

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 12 Jul 2001 19:02:40 -0500

Adam

>a specific IP address at a particular port."

Possibly....... use an Options Method to query a (Proxy?) server for its (known
domain) capabilities for transcoding your example above: 

can you/anybody "take (this) incoming media encoded by this codec from this
port, transcode it to a (specific) different codec....." 

and have that asked Server return the address of a Server/transcoder/B2BUA
(pre-negotiated of not, but it should tell it so) that could perform that
function.... Perhaps that might mean the initial Server returns a 3XX redirect
to that specific 'other' Server. Perhaps even a second Options Method query is
then sent to this redirected (to) Server (from the first response) from the
originating UA in need....

Or come up with a well-known Multicast for transcoders asking for one that has
this capability and the asking UA sends a redirect to the originating UA with
the responding transcoders address and whatever other capabilities or
authentications are required for this multi-legged group of transactions just
to have a single(?) stream transcoded between two (or more) UA's.

just thinking quickly and without thinking it thoroughly (hence the lack of
clarity -- but you might understand the essence to make a comment)

>this list to find any beyond those that have already been mentioned.
*************************************
"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
18581 N. Dallas Parkway
Dallas, Texas 75287
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Jul 2001 20:57:00 +0300

Hello,

> this list to find any beyond those that have already been mentioned.

An example of transcoder invokation using 3pcc can be found at:
http://www.hut.fi/~gonzalo/papers/draft-camarillo-3pcc-qos-00.txt

Note that this is an already expired draft though.

I fully agree with Adam that we do not have to design architectures that
send signalling thru a transcoder. Using 3pcc or H.248 (as it was also
suggested) allows to implement media-related services such as adding
music or manipulating video images in a much nicer way.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]