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

[Gonzalo Camarillo <[e-mail]>]

Hello,

> 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.

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


> /a
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[e-mail]]
> > Sent: Thursday, July 12, 2001 10:00 AM
> > To: '[e-mail]'; 'Michael Thomas'
> > Cc: 'Henning Schulzrinne'; [e-mail]; Paul Kyzivat;
> > Jay Batson; [e-mail]
> > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest
> > proposa l.)
> >
> >
> > 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: [e-mail] [mailto:[e-mail]]
> > > Sent: Wednesday, July 11, 2001 8:53 PM
> > > To: 'Michael Thomas'; [e-mail]
> > > Cc: 'Henning Schulzrinne'; [e-mail];
> > Paul Kyzivat;
> > > Jay Batson; [e-mail]
> > > Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest
> > > proposal.)
> > >
> > >
> > > > From: Michael Thomas [mailto:[e-mail]]
> > > >
> > > > [e-mail] 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 [e-mail] for questions on current sip
> > > Use [e-mail] 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 [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip

-- 
Gonzalo Camarillo                    Phone :   [phone]
Columbia University                  Mobile:  [phone]
472 Computer Science Building        Fax   :  [phone]
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [e-mail]

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