Subject: RE: [Sipping] SIP Support for Hearing and Speech Impaired Users

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Aug 2001 19:25:44 +0100

Yes, I agree we want transcoder free operation, it both ends can talk the
same language.

The main point I was making is that if we rely on the terminating end
supporting new procedures to invoke transcoders, then we aren't solving that
part of the problem when we are talking about "legacy" SIP phones at the
terminating side that currently do not implement those procedures.
Currently, its always seems easier to update the infrastructure rather than
the end terminals.

If you can come up with something that allows either the calling OR the
called side to identify the need for a transcoder, and then to invoke the
transcoder, then that would be a possible alternative.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Gonzalo Camarillo[SMTP:[email-masked]]
> Sent: 	13 August 2001 18:03
> To: 	Drage, Keith (Keith)
> Cc: 	Michael Hammer; [email-masked]; sipping; Jeff Van Dyke; Andy
> Spitzer
> Subject: 	Re: [Sipping] SIP Support for Hearing and Speech Impaired
> Users
> 
> Hello Keith,
> 
> You are describing how GSM works. Assume that we are installing the
> first GSM network (some years ago). GSM terminals do not speak G.711.
> All the calls from a GSM terminal go thru an MSC. We want new GSM
> terminals to be able to speak to old fixed phones, of course. Fixed
> phones speak G.711. Therefore, every time a GSM terminal makes a call
> that "might" end up in a fixed phone the "intelligent" MSC decides on
> behalf of the terminal that transcoding is needed.
> 
> After transcoding to G.711 is applied, the call happens to end up in
> another GSM terminal... oops, the terminating MSC has to apply
> transcoing again!!
> 
> In the paragraphs above replace GSM by 3G and MSC by CSCF and you will
> find out why I do not like proxies that invoke transcoding services. If
> we let the CSCF make a lot of decisions on behalf of the terminals we
> will have to design "3G transcoder free" calls in a near future (the
> same way as now we are designing GSM transcoder free and tandem free
> systems).
> 
> Regards,
> 
> Gonzalo
> 
> "Drage, Keith (Keith)" wrote:
> > 
> > Fine, except that when we have the scenario where the terminating
> endpoint
> > is one of those existing SIP phones that supports only G.711, and a 3GPP
> SIP
> > mobile wants to talk to it, we still want transcoding to be provided.
> > 
> > In this case, because the calling 3GPP SIP mobile is trying to talk the
> less
> > "standard" codec, it could be assumed that the service needs to be
> provided
> > on behalf of the calling user. The 3GPP SIP mobile is not using G.711
> > because it is bandwidth inefficient, which would be highly detrimental
> to
> > the calling network operator.
> > 
> > In this case, therefore, it is entirely reasonable that the entities in
> the
> > calling 3GPP network will have to find some way of providing the
> > transcoding.
> > 
> > Or, instead of upgrading all those G.711 SIP phones with other codec
> > support, we have to upgrade them with the redirect to a transcoder
> instead.
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: [email-masked]
> > 
> > > ----------
> > > From:         Gonzalo
> Camarillo[SMTP:[email-masked]]
> > > Sent:         08 August 2001 23:27
> > > To:   Michael Hammer
> > > Cc:   [email-masked]; sipping; Jeff Van Dyke; Andy Spitzer
> > > Subject:      Re: [Sipping] SIP Support for Hearing and Speech
> Impaired
> > > Users
> > >
> > > Hello,
> > >
> > > Letting proxies detect the missmatch of codecs and invoke transcoding
> > > services is an old idea. This is actually what an MSC does in a GSM
> > > call. And that's why the call between two GSM phones has two
> transcoding
> > > points, when it should be transcoder-free. That's also why
> > > transcoder-free operations had to be defined, adding complexity to
> GSM.
> > >
> > > Let's keep things simple. Let's the end systems invoke transcoding
> > > services if they want to. They can use 3pcc for instace: here you have
> > > an example of such an invokation.
> > > http://www.hut.fi/~gonzalo/papers/draft-camarillo-3pcc-qos-00.txt
> > >
> > > In the scenarios where we do not really need to break the end to end
> > > negotiation of media parameters, let's keep it e2e.
> > >
> > > Regards,
> > >
> > > Gonzalo
> > >
> > >
> > > Michael Hammer wrote:
> > > >
> > > > Eric,
> > > >
> > > > As much as I would like to believe in magic, resources are provided
> in
> > > the
> > > > network for the benefit of either the calling or called party.  In
> this
> > > > case, it is the called party that benefits.  Both your and Mark's
> > > > approaches (with which I agree) lay the responsibility on the called
> > > party
> > > > or its supporting proxy to recognize the mismatch in desired media
> and
> > > to
> > > > invoke the translator as needed.  In the first case, I would assume
> the
> > > > magic is based on some type of registration information (profile?)
> > > > associated with the called party, in the second case the called
> party
> > > > explicitly asks for the service.
> > > >
> > > > Mike
> > > >
> > > > At 10:30 AM 8/8/2001 -0400, Eric Burger wrote:
> > > > >We have two approaches.  The first approach would be more like your
> "it
> > > > >happens by magic in the network" approach.  In this scenario, a
> proxy
> > > > >detects the mismatch in SDP and requests the transcoding service in
> the
> > > > >manner of a 2-party conference bridge.  The second approach is
> where
> > > the
> > > > >terminating UA requests the transcoding service and returns the
> > > transcoding
> > > > >service's SDP to the calling UA.
> > > > >
> > > > >Service providers are more likely to use the first approach for
> peering
> > > or
> > > > >as a value-add service.  Phone manufacturers or ingress proxies are
> > > more
> > > > >likely to use the second approach.
> > > > >
> > > > >-----Original Message-----
> > > > >From: Mark Watson [mailto:[email-masked]]
> > > > >Sent: Wednesday, August 08, 2001 9:50 AM
> > > > >To: 'eburger'; sipping
> > > > >Cc: Jeff Van Dyke; Andy Spitzer
> > > > >Subject: RE: [Sipping] SIP Support for Hearing and Speech Impaired
> > > Users
> > > > >
> > > > >
> > > > >All,
> > > > >I think there's a general problem, in that many types of media can
> in
> > > > >principle be translated (with varying degrees of ease) in to many
> other
> > > > >types of media.
> > > > >What would be useful is a generic way for the parties to a session
> to
> > > > >specify their preferred media combinations and for the appropriate
> > > > >translators to be automatically brought into the session - such a
> > > mechanism
> > > > >can be defined indepent of the media types involved and the
> translators
> > > > >available. (Perhaps this is what your draft does, Eric - I'll look
> out
> > > for
> > > > >it)
> > > > >I'd like to think there was a way of doing this which also
> optimised
> > > the use
> > > > >of resources - so if Party A wants to receive only Media Type 1
> > > (Media1),
> > > > >and Party B wants to send Media Type 2 (Media2) and an
> Media2->Media1
> > > > >translator is available, then there should be no need to send
> Media2 to
> > > A
> > > > >(indeed, the reason A likes Media1 might be because it is lower
> > > bandwidth
> > > > >than Media2). Media2 should only be sent to the translator.
> Equally,
> > > though,
> > > > >the case where A wants *both* MT1 and MT2 should be supported.
> > > > >Regards,
> > > > >Mark Watson
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> > > > >This list is for NEW development of the application of SIP
> > > > >Use [email-masked] for questions on current sip
> > > > >Use [email-masked] for new developments of core SIP
> > > >
> > > > _______________________________________________
> > > > Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use [email-masked] for questions on current sip
> > > > Use [email-masked] for new developments of core SIP
> > >
> > > --
> > > 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]
> > >
> > > _______________________________________________
> > > Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments of core SIP
> > >
> 
> -- 
> 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]
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 Aug 2001 22:03:10 +0300

Hello Keith,

> terminating side that currently do not implement those procedures.

[snip]

> transcoder, then that would be a possible alternative.

Let's assume that A and B do not have any codec in common. A INVITEs B.
If B is able to use 3pcc to invoke a transcoder, B will INVITE the
transcoder, and will return the SDP provided by the transcoder to A in
the 200 OK (or in 18x responses, since 100rel will be used).

If B does not support 3pcc, B will return to A a 4xx response saying
that there is a codec missmatch. A then will use 3pcc to invoke
transcoding services and will re-INVITE B with the SDP provided by the
transcoder.

Therefore, as long as one of the parties (any of them) supports
transcoder invokation the call will be successful.

Regards,

Gonzalo