ES2890653T3 - Formato de carga útil RTP híbrido - Google Patents
Formato de carga útil RTP híbrido Download PDFInfo
- Publication number
- ES2890653T3 ES2890653T3 ES14824574T ES14824574T ES2890653T3 ES 2890653 T3 ES2890653 T3 ES 2890653T3 ES 14824574 T ES14824574 T ES 14824574T ES 14824574 T ES14824574 T ES 14824574T ES 2890653 T3 ES2890653 T3 ES 2890653T3
- Authority
- ES
- Spain
- Prior art keywords
- payload
- codec
- header
- data
- mode
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000011664 signaling Effects 0.000 claims abstract description 42
- 238000000034 method Methods 0.000 claims abstract description 36
- 230000002776 aggregation Effects 0.000 claims abstract description 18
- 238000004220 aggregation Methods 0.000 claims abstract description 18
- 230000006978 adaptation Effects 0.000 claims abstract description 15
- 230000005540 biological transmission Effects 0.000 claims abstract description 15
- 230000005236 sound signal Effects 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 6
- 238000004891 communication Methods 0.000 claims description 4
- 238000005516 engineering process Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 241000197200 Gallinago media Species 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- G—PHYSICS
- G10—MUSICAL INSTRUMENTS; ACOUSTICS
- G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
- G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
- G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
- G10L19/16—Vocoder architecture
- G10L19/167—Audio streaming, i.e. formatting and decoding of an encoded audio signal representation into a data stream for transmission or storage purposes
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- Health & Medical Sciences (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- Acoustics & Sound (AREA)
- Theoretical Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
- Time-Division Multiplex Systems (AREA)
Abstract
Un método para dar formato a una carga útil para la transmisión de datos de códec de voz multimodo o datos de códec de audio multimodo, comprendiendo el método: - decidir (103) en base a un modo de códec y una tasa de bits si se usa un formato de carga útil con cabecera o sin cabecera, en donde si se usa el formato de carga útil con cabecera con una cabecera de carga útil la cabecera de la carga útil comprende información de señalización, en donde la información de señalización se asocia con al menos uno de entre: una identificación de modo de códec, una tasa de bits, una adaptación de modo, una solicitud de modo de códec, un ancho de banda de audio, un modo interno de códec y la agregación de tramas; y - paquetizar (105) unos datos de carga útil RTP con o sin la cabecera de carga útil dependiendo de la decisión.
Description
DESCRIPCIÓN
Formato de carga útil RTP híbrido
Campo técnico
La presente solicitud se refiere de manera general a una codificación de voz/audio, y en concreto a un método y aparato para dar formato a una carga útil para la transmisión de datos de códec de voz/audio multimodo.
Antecedentes
El Proyecto de Asociación de 3a Generación 3GPP especifica la Multitasa Adaptativa (AMR) y la Banda ancha Multitasa adaptativa (AMR-WB) como códecs de voz obligatorios para servicios de voz en redes 3G. Estos códecs son obligatorios también para el servicio de Voz 3GPP sobre IP (VolP) que se especifica dentro de la telefonía multimedia 3GPP a través del Subsistema Multimedia IP (IMS). El pliego de condiciones para el manejo e interacción de medios es la TS 26.114 3GPP. A pesar del estado obligatorio de estos códecs existen actualmente actividades en el 3GPP para especificar un nuevo códec de voz que permitirá incluso una mayor calidad de servicio que la que es posible con AMR-WB, el códec de Servicio de Voz Mejorado (EVS).
Sin embargo, introducir un nuevo códec de voz en un sistema de comunicaciones de voz puede ser problemático en algunos aspectos. Un problema es que siempre existe una base instalada de equipo heredado (tanto terminales como infraestructura de red) que sólo soporta los códec 3GPP existentes o uno de ellos, por ejemplo el AMR-WB, en lugar del nuevo códec. Esto puede llevar a problemas de interoperabilidad en los que la comunicación entre el equipo nuevo y el heredado no es posible a menos que se implementen los mecanismos apropiados en el sistema. La maneras tradicionales de abordar este problema es la provisión de transcodificadores en por ejemplo las puertas de enlace de medios que traducen entre los formatos nuevo y antiguo, o la provisión de los códecs heredados además del nuevo códec en los nuevos terminales que permita elegir el formato de codificación heredado cuando se establezca una conexión a un terminal heredado. Este último método requiere que exista un intercambio de capacidad entre los terminales antes de la conexión de voz real que identifique el códec común que soportan ambos terminales. Dentro del IMS se usa el protocolo de descripción de sesión (SDP) IETF RFC 4566 para llevar a cabo este intercambio de capacidad.
Las maneras anteriores de asegurar la interoperabilidad al introducir un nuevo códec en un sistema de comunicación no son las únicas posibilidades y tienen diversos inconvenientes. La provisión de transcodificadores implica equipo adicional que eleva la inversión en la red y los costes de mantenimiento. La transcodificación se asocia también con las degradaciones de calidad de voz indeseadas. Usar el intercambio de capacidad entre los terminales antes de la llamada es una manera muy elegante, que sin embargo no siempre puede ser posible. Ejemplos donde no es siempre posible son la conferencia multiparte, los escenarios de traspaso con usuarios móviles itinerando a celdas sin soporte de Servicio de Telefonía Multimedia para IMS (MTSI), la mensajería de voz. También desde el punto de vista de la implementación de terminal puede ser indeseable proporcionar soporte para el conjunto completo de códecs nuevos y heredados ya que esto podría aumentar los costes de licencias de implementación y tecnología.
En consecuencia, existe una necesidad de permitir la introducción de nuevos códecs de voz en los sistemas de telecomunicación para proporcionar una calidad de servicio mejorada, en concreto a los sistemas 3GPP, mientras que se mantiene la retrocompatibilidad con los códecs antiguos o heredados.
Por tanto, una tercera posibilidad elegida por el 3GPP para el códec EVS para interoperar con un equipo AMR-WB heredado es la inclusión de modos de codificación interoperable AMR-WB como una parte del códec EVS además de modos de operación completamente nuevos. Este enfoque alivia todos los problemas discutidos anteriormente. Sin embargo, el 3GPP no especifica soluciones sobre cómo señalizar desde un UE del lado del envío a un UE del lado de la recepción cuál de los modos EVS disponibles, el AMR-WB interoperable o no interoperable se ha usado para codificar y a qué tasa de bits.
Una posible solución de este problema de señalización se describe en el documento US20120035918: “Method and arrangement for providing a backwards compatible payload format”. Esta solución se refiere a los métodos de introducción de nuevos códecs de voz en sistemas heredados. En concreto, esta solución describe un formato de carga útil retrocompatible que permite la inclusión de un nuevo códec de voz. En una aplicación concreta de esta solución los modos interoperables AMR-WB del códec EVS son paquetes del Protocolo de Transporte en tiempo Real (RTP) tales como los paquetes AMR-WB según el IETF RFC 4867. Sin embargo, se incluye un bit de señalización en los bits no usados anteriormente de los nuevos modos no interoperables del códec EVS. Si se configura el bit correspondiente en la cabecera de carga útil RTP, esto se trata como una señal de que los bits de datos de carga útil de voz/audio que siguen representan un flujo de bits asociado con los nuevos modos no interoperables del códec EVS en lugar de los modos interoperables AMR-WB.
El problema con el enfoque anteriormente descrito del documento US20120035918 es sin embargo que un formato de carga útil RTP correspondiente para el códec EVS inevitablemente hace uso de la cabecera de carga útil RTP del códec heredado incluido (AMR-WB). En aplicaciones donde los recursos de transmisión están extremadamente limitados dicha sobrecarga no es deseable.
Para solucionar este problema de sobrecarga existen otras soluciones que no usan una cabecera de carga útil RTP para nada (ejemplo EVRC (Códec de Tasa Variable Mejorada) o códec ITU-T G.729). La información de señalización necesaria relacionada con la carga útil se deriva en tales casos a partir de otros elementos de información de los paquetes RTP, como por ejemplo la información proporcionada en los campos de cabecera IP/UDP/RTP que son diferentes de una cabecera de carga útil RTP. Un elemento de información importante que se puede usar es el tamaño de la carga útil RTP o el tamaño del paquete. Si esta claro que cada paquete RTP siempre contiene sólo una trama única de voz/audio codificado (correspondiente a por ejemplo 20 ms de voz/audio), entonces la tasa de bits usada para codificar la señal de voz/audio se obtiene fácilmente a partir del tamaño de carga útil RTP. Esto es una solución práctica en el caso de que el códec use sólo un conjunto limitado y discreto de tasas y si los modos de operación del códec están directamente conectados a las tasas de bits respectivas. En caso, sin embargo, de que se use agregación de tramas, lo que significa que se transmiten una pluralidad de tramas de voz/audio codificadas dentro de un paquete, esta solución no siempre funciona. Esto se ejemplificará de la siguiente manera:
Suponga que hasta 2 tramas codificadas se pueden transmitir en cada paquete RTP y que el códec tiene dos modos de códec con tasas de 8 kbps y 16 kbps. Cada trama corresponde a 20 ms. Se supone ahora además que el emisor opera con agregación de tramas y que coloca dos tramas en cada paquete. En el ejemplo se supone además que la primera trama del paquete se codifica con 8 kbps, lo que significa que comprende 20 bytes de datos. La segunda trama se codifica con 16 kbps lo que significa que la trama de voz codificada comprende 40 bytes de datos. El tamaño de la carga útil del paquete que contiene ambas tramas agregadas es por tanto de 60 bytes. El receptor recibe este paquete RTP con una carga útil de 60 bytes y la tarea es averiguar de qué manera los datos incluidos dentro se codifican. El receptos podría concluir ahora a partir de la recepción de este paquete y su tamaño de carga útil que bien contiene 3 tramas de datos codificados a 8 kbps o una trama codificada a 16 kbps y una trama codificada a 8 kbps. En el último caso aún no está claro si la trama codificada a 8 kbps viene primera o segunda. Como resulta evidente a partir del ejemplo, esta ambigüedad hace imposible para el decodificador en el receptor decodificar las tramas recibidas de una manera apropiada. Por tanto, permitir la agregación de tramas (o no excluir la posibilidad de la agregación de tramas) puede introducir ambigüedades que hacen imposibles los formatos RTP sin cabecera. La agregación de tramas es sin embargo una característica muy deseable para VoIP para ciertas redes IP con por ejemplo acceso WLAN.
Otro problema pertenece a la posible interoperación de los modos interoperables AMR-WB del códec EVS con un equipo heredado que sólo soporta el códec AMR-WB. Con el propósito de la adaptación de modo el formato de carga útil RTP AMR-WB proporciona en su cabecera un campo de 4 bits de anchura para transportar las así denominadas CMR (solicitudes de modo de códec).El propósito de las CMR es señalizar a un UE del lado emisor el modo de códec preferido que debería usar en su operación de codificación. Esto permite la adaptación de la tasa de bits usada en respuesta a por ejemplo los cambios del canal de transmisión o las limitaciones de capacidad del sistema, la así denominada adaptación AMR que usa señalización en banda. Un formato de carga útil sin cabecera del códec EVS para los modos interoperables AMR-WB no sería capaz de transportar estas CMR y por tanto no sería posible en escenarios de interoperación con adaptación de modo de códec de equipo AMR-WB heredado con base en el concepto de señalización en banda AMR usando CMR. Los documentos US 2007/086434, US 2006/262788, WO 02/45357 y WO 02/15625 describen sistemas adicionales de la técnica anterior.
Compendio
El objetivo de las presentes realizaciones es solucionar o al menos aliviar al menos uno de los problemas anteriormente mencionados.
El objetivo es proporcionar un formato de carga útil RTP eficiente para un códec multimodo de voz/audio que comprende al menos dos modos de operación de los cuales uno puede interoperar con un códec que ya está desplegado por un equipo heredado existente. El problema por un lado es hacer el formato de carga útil tan eficiente como sea posible en el sentido de que contenga tan poca sobrecarga como sea posible. Al mismo tiempo no debería haber limitaciones con respecto a las posibilidades para agregar una multitud de tramas codificadas en una paquete RTP. Además, en los casos en que se usa el modo de codificación heredado en un contexto de interoperación con un equipo heredado, el formato de carga útil RTP debería ser capaz de transmitir la información de señalización adicional necesaria para la interoperación con el equipo heredado.
Más específicamente, el códec que ya está desplegado por un equipo heredado existente puede ser AMR-WB y la información de señalización relacionada con la interoperación con el equipo heredado que usa AMR-WB pueden ser los datos de adaptación de modo AMR-WB e incluso más específicamente la información CMR.
La invención está definida mediante las reivindicaciones independientes. En las reivindicaciones dependientes se describen realizaciones preferidas adicionales.
Dibujos
Para un entendimiento más completo de las realizaciones de ejemplo de la presente invención, se hace ahora referencia a las siguientes descripciones tomadas en conexión con los dibujos adjuntos en los que:
La Figura 1 ilustra un ejemplo del método realizado por un codificador.
La Figura 2 es un diagrama de flujo de un algoritmo de decisión para decidir si se usan paquetes con cabecera o sin cabecera.
La Figura 3 ilustra un ejemplo de un método de desempaquetado realizado por un decodificador.
La Figura 4 ilustra un esquema de ejemplo de carga útil RTP sin cabecera para el modo 12,65 AMR-WB.
La Figura 5 ilustra un esquema de ejemplo alternativo de carga útil RTP sin cabecera para el modo 12,65 AMR-WB con desplazamiento.
La Figura 6 muestra un primer ejemplo de un aparato según una realización de la invención.
La Figura 7 muestra un segundo ejemplo de un aparato según una realización de la invención.
La Figura 8 muestra un tercer ejemplo de un aparato según una realización de la invención.
Descripción detallada
Las realizaciones de la invención tal como se define por las reivindicaciones usan una combinación de formato de carga útil RTP con cabecera y sin cabecera. Para garantizar que el uso del formato sin cabecera eficiente no lleva a ambigüedades de tamaño de carga útil RTP que hagan imposible la decodificación apropiada por el receptor, el formato sin cabecera sólo se usa de manera condicional en ciertos casos. En otro caso se usa un formato de carga útil RTP con cabecera con cabecera de carga útil, donde la cabecera de carga útil incluye toda la información de señalización relevante requerida para identificar el modo de códec y la tasa de bits usada para codificar los datos incluidos en la carga útil RTP. Parte de la idea es para especificar un conjunto de tamaños de paquetes RTP que se relacionan directamente y de forma única con la tasa de bits y el modo de codificación usados para codificar la carga útil de voz/audio. En caso de que se use el formato de carga útil con cabecera, al crear el paquete RTP su tamaño es controlado de manera que no coincida con ninguno del conjunto de tamaños de paquetes RTP únicos reservados para el formato de carga útil sin cabecera. Si este es el caso, el tamaño de paquete rTp es ajustado añadiendo bytes de relleno hasta que se resuelva el conflicto con los tamaños de paquetes reservados. Además, los datos asociados con el modo de códec a usar para interoperar con el equipo heredado se transmite usando el formato de carga útil sin cabecera eficiente. La información de señalización adicional necesaria para la interoperación con el equipo heredado se transmite usando bits de reserva en la carga útil bien a través de la difusión de esta información en el tiempo o a través de asignarla a los bits de reserva disponibles.
Se describe una realización como el método 100 siguiente ilustrado en la Figura 1. En un primer paso 101 se define el conjunto de modos de códec y/o tasas de bits para los que la carga útil RTP debería permitir la transmisión eficiente sin cabecera de carga útil RTP. Este conjunto corresponde luego al conjunto de tamaños de carga única protegidos o únicos, llamados “conj_prot”.
Como un ejemplo se supone ahora que el formato de carga útil RTP permite la transmisión de carga útil ARM-WB heredada y de carga útil no interoperable con AMR-WB. El conjunto de tasas AMR-WB que pertenecen al conjunto se muestra en la Tabla 1 siguiente y comprende los 9 modos AMR-WB y el modo SID (Descriptor de Inserción de Silencio) usado para la operación de transmisión Discontinua (DTX)/ruido de confort:
Tabla 1: Modos/tasas interoperables AMR-WB
El conjunto de tasas/modos no interoperables (es decir, no interoperables con el códec AMR-WB heredado) que pertenecerán al conjunto de tasas/modos que se pueden transmitir en el ejemplo sin cabecera de carga útil RTP se muestra en la siguiente Tabla 2:
Tabla 2: Modos no interoperables AMR-WB para los que se prefiere la paquetización sin cabecera
Por tanto, en el ejemplo el conjunto de tamaños de carga útil protegidos (únicos) es el siguiente:
Conj_prot = {7, 10, 14, 17, 18, 20, 23, 24, 32, 33, 36, 40, 41,46, 50, 58, 60, 61}.
Al conjunto adicional siguiente de tasas de bits que pertenecen al modo no interoperable no se transmitirá en el siguiente ejemplo sin cabecera de carga útil RTP sino con cabecera de carga útil, véase la siguiente Tabla 3:
Tabla 3: Conjunto de modos/tasas no interoperables para los que se prefiere la paquetización con cabecera
En un siguiente paso 103 el método decide si se usa la paquetización RTP con o sin cabecera. Como ejemplo, en caso de que se use la agregación de tramas con más de una trama codificada por paquete, se usará la paquetización RTP con cabecera. No existe por tanto riesgo de que la agregación de múltiples tramas dentro del paquete RTP pueda conducir a ambigüedades haciendo difícil o imposible para el receptor decodificar la carga útil de manera correcta. Además, pueden existir más condiciones para las que se seleccione la paquetización con cabecera en lugar de sin cabecera. Por ejemplo, esto puede depender de la tasa de bits del modo de códec transmitido. En concreto, si la tasa de bits es grande, la sobrecarga asociada con la paquetización con cabecera puede ser relativamente pequeña y por tanto aceptable. Otra razón para elegir la paquetización con cabecera puede ser por ejemplo la necesidad de transmitir información adicional en el paquete RTP que se debería colocar en la cabecera de la carga útil. Como un ejemplo esto podrían ser bits de información relacionados con la adaptación de modo (como las CMR) u otros datos de señalización específicos de códec (como la información de ancho de banda de audio o la información de modo interno de códec) que necesitan ser transportados hasta el receptor ara operar el decodificador de manera apropiada.
Como un ejemplo de este paso el diagrama de flujo de la Figura 2 ilustra un algoritmo 200 de decisión para decidir si se usa paquetización con cabecera o sin cabecera. En este ejemplo se elige siempre paquetización con cabecera si
se usa agregación de tramas con múltiples tramas por paquetes, selección en el bloque 201, si la tasa de bits excede los 24,4 kbps, selección en el bloque 203, o en caso de una característica especial que lo requiera, selección en el bloque 205. Tal característica especial puede ser, como se explicó anteriormente, la disponibilidad de datos de adaptación de modo u otros datos de señalización específicos de códec. Por tanto, en este ejemplo los parámetros de decisión de si usar paquetización sin cabecera 207 o no 209 son:
• Agregación de tramas (num_agr)
• tasa de bits, o número de bytes (octetos) por trama
• Característica especial que requiere formato de carga útil con cabecera
En un siguiente paso 105, como parte de la paquetización, se determina el tamaño de la carga útil RTP (o de manera correspondiente del paquete RTP). Esto puede ser conseguido por el siguiente algoritmo en pseudocódigo de estilo de programación en c, con base en la determinación anterior de si se usará la paquetización con cabecera o sin cabecera:
• Si sin cabecera entonces
- Tamaño-carga útil = octetos(0)
• En otro caso
- Para Tamaño-carga útil = 0, i = 0; i < num_agr; i++
Tamaño-carga útil+ = octetos (i) 1
• Mientras Tamaño-carga útil en conj_prot
Tamaño-carga útil++
En el pseudocódigo anterior ‘octetos’ corresponde al tamaño en bytes de los datos de voz/audio de una trama i dada (la cuenta comienza en 0). ‘num_agr’ es el número de tramas agregadas por paquete, es decir, 1 en el caso de que no se use agregación, en cualquier otro caso num_agr es mayor que 1.
En el extremo receptor la despaquetización ha de realizar un algoritmo 300 inverso al anterior, para determinar las tramas de datos de voz/audio decodificadas en el paquete recibido y la información de señalización asociada tal como se ilustra en la Figura 3. Por ejemplo, el despaquetizador puede determinar primero si el tamaño de la carga útil corresponde a alguno de los miembros del conjunto de tamaños de carga útil protegidos o únicos, “conj_prot”, tal como se muestra en el bloque 301. En ese caso se usó la paquetización sin cabecera y el tamaño de la carga útil identifica de manera única el códec usado y la tasa de bits, tal como se muestra en el bloque 303. En otro caso, se usó la paquetización con cabecera. En ese caso, el despaquetizador lee primero la cabecera de carga útil RTP (o al menos una primera cabecera de carga útil RTP), tal como se muestra en el bloque 305. La cabecera de carga útil contiene toda la información de señalización necesaria sobre la tasa y el modo de códec usado para codificar la carga útil de voz/audio y si por ejemplo se usó alguna agregación de tramas, lo cual podría implicar que puede existir información adicional de cabecera asociada con tramas de voz/audio codificadas adicionales. Se debería observar que puede existir una cabecera RTP para cada trama de voz/audio, o puede existir sólo una cabecera RTP única incluso en el caso de que se use agregación de tramas. Información de señalización adicional potencial que puede ser parte de la cabecera RTP puede ser extraída también por el método de despaquetización del receptor.
En un paso adicional del método los datos asociados con el modo de códec a ser usado para interoperar con un equipo heredado son tratados de manera que puedan ser transmitidos junto con la carga útil asociada con ese modo de códec y usando la paquetización sin cabecera eficiente. Se debería observar que esta información de señalización puede ser necesaria para la interoperación con un equipo heredado. Mientras en un principio pueda parecer imposible transmitir dicha información extra en el caso de la paquetización sin cabecera, existe aún la posibilidad en caso de que existan bits sin usar en la carga útil de voz/audio. Esto se describirá en detalle en las siguientes realizaciones.
Una de dichas realizaciones se explica con el ejemplo concreto del modo interoperable AMR-WB a ser usado para interoperar con un equipo heredado. Tal como se puede ver a partir de la Tabla 4 a continuación, dependiendo del modo usado los bits a ser transmitidos por trama generalmente no son números enteros múltiplos de 8, que es el caso en la paquetización RTP. Por tanto, cuando se empaquetan estos bits de carga útil en octetos (o bytes) de 8 bits, algunos bits de la carga útil empaquetados en bytes se mantienen sin usar. En la tabla a continuación, estos bits sin usar se representan como ‘bits de reserva’. Tal y como se puede ver, hay siempre un mínimo de 3 bits de reserva disponibles.
Tabla 4: Número de bits de reserva en la paquetización d RTP de los datos de carga útil del códec AMR-WB
El primer caso a considerar es que la cantidad de información de señalización extra no exceda los bits de reserva disponibles. Entonces, el método puede usar de manera directa los bits de reserva para la transmisión de la información extra. Como un ejemplo del caso se supone que la carga útil de voz/audio corresponde al modo#2 AMR-WB (es decir 12,65) de la tabla anterior. Y además se supone que la información extra a ser transmitida comprende 3 bits. Entonces, los bits de datos de ese modo son los bits d(0) a d(252). Tal como se muestra en la Figura 4,estos se pueden colocar en el paquete RTP sin cabecera comenzando desde el bit 0 del octeto 0. Los 3 bits S de señalización extra se colocan después del último bit d(252) de datos.
Se debería observar aquí que el esquema anterior es sólo un ejemplo específico. En concreto, puede ser útil colocar los bits de datos AMR_WB en el paquete RTP con un desplazamiento, en caso de que por ejemplo, los paquete vayan a ser reempaquetados en una puerta de enlace de medios usando otro formato de carga útil RTP, por ejemplo el RFC 4867 con empaquetamiento eficiente de ancho de banda. Tal ejemplo se muestra por ejemplo en el esquema alternativo de la Figura 5. Debido al desplazamiento, el primer bit de datos de la carga útil AMR-WB no es d(0) sino por ejemplo d(2). Los bits d(0) y d(1) se insertan después al final de los bits de carga útil ARM-WB.
El caso más general es sin embargo que existan más bits de señalización que puedan ser transportados con el bit de reserva. En ese caso, una primera realización preferida es para difundir la transmisión de la información de señalización a tiempo. Con ese fin, la información de señalización extra es primero diezmada en el tiempo. Suponga que esta información de señalización extra llega con la misma frecuencia que las tramas de voz/audio codificadas, se debe asegurar primero que estos datos están suficientemente diezmados (o submuestreados) para que la tasa requerida para transmitirlos no exceda la tasa de transmisión disponible que puede ser conseguida usando los bits de reserva. Se ha de observar que en muchos casos dicha información de señalización se puede diezmar sin un impacto significativo en el servicio. En una realización más concreta, se puede suponer que estos datos son CMR a usar para la adaptación del modo de códec. Este tipo de datos se pueden diezmar sin un gran impacto. En un ejemplo incluso más concreto de esta realización, se supone que existen 4 bits CMR que necesitan ser señalizados cada 20 ms. Primero, estos datos se diezman de manera que existan sólo 4 bits c Mr cada 40 ms, es decir, cada otra trama. Después estos 4 bits CMR diezmados se dividen en dos partes de 2 bits y se transmiten en tramas adyacentes: Una primera parte de dos bit se transmite con una primera trama, la parte de dos bits restante le sigue con una segunda trama. Si se transmiten las partes de dos bits de los dos bits menos significativos o de los dos bits más significativos se indica con un bit LSB.
Esto se ilustra incluso en más detalle como sigue. Los 4 bits CMR se denominan (c3, c2, c1, c0), entonces la tupla (c3, c2) son los dos bits más significativos, la tupla (c1, c0) son los dos bits menos significativos. En una primera trama los tres bits S de la Figura 5 o 6 pueden transportar los bits (c1, c0, L), donde L=1 indica que c1 y c0 son LSB. En una segunda trama correspondiente los tres bits S transportan los bits (c3, c2, L), donde L=0 indica que c3 y c2 son LSB.
En otra realización, la información de señalización se reduce a una cantidad que pueda ser transportada usando los bits de reserva disponibles reasignándola los bits de reserva disponibles. Considere de nuevo el ejemplo en que los 4 bits CMR necesitan ser reducidos a 3 bits de reserva disponible. Ya que los bits CMR codifican solicitudes para uno de los modos AMR-WB mostrados anteriormente, una posibilidad es que las CMR para 8 de los 9 modos AMR_WB (todos excepto el 23,05) se señalicen con los tres bits de reserva. Las CMR para el modo 23,05 se reasignan a un modo vecino (19,85). Otro ejemplo es que sólo las CMR correspondientes a los modos 6,6, 8,85, 12,65, 15,85 y 23,85 están permitidos y cualquier CMR para un modo AMR-WB diferente se reasigna al modo AMR.WB permitido más
cercano. Observe que en ese contexto estos 5 modos AMR-WB son los modos AMRWB relevantes a ser usados en servicios de voz 3GPP de conmutación de circuitos (CS). En estos dos ejemplos ahora es posible usar los tres bits S disponibles de manera directa para transmitir la información de señalización que se reasignó.
Una realización adicional puede funcionar de manera similar a la realización anterior con la reasignación pero sólo para las CMR para el subconjunto de modos que están permitidos para ser señalizados usando directamente los bits S. Debería existir una CMR para otro modo, se podría elegir paquetización con cabecera en lugar de sin cabecera. En la cabecera de carga útil RTP usada en ese caso, podría haber suficiente espacio de señalización para transportar las CMR para este otro modo.
La siguiente realización según la Tabla 5 muestra un ejemplo de una cabecera de carga útil RTP que se podría usar para la paquetización con cabecera. Según esta realización se define una cabecera de 8 bits con los siguientes elementos de señal:
• FT (5 bits): tipo de trama
usado para la señalización de los modos interoperables y no interoperables AMR-WB.
• F (1 bit): continuación
Si se establece a 1, indica que esta trama es seguida por otra trama de voz en esta carga útil; si se establece a 0, indica que esta trama es la última trama en esta carga útil.
• CMR_ext/Reserva (1 bit): bit CMR extra
Puede ser usado como parte de las realizaciones donde las CMR para los modos interoperables AMR-WB que no están permitidos han de ser señalizados por los bits de reserva. Este bit CMR_ext adicional permite aumentar el espacio de señalización de las CMR a 4 bits, lo cual es suficientemente grande para señalizar las CMR para todos los modos AMR_WB. En otro caso podría ser de reserva/sin uso. Este bit podría ser usado por ejemplo para extender el espacio de señalización más para los modos no interoperables.
• Reserva (1 bit)
Actualmente no usado. Se podría usar para extender el espacio de señalización para permitir modos/tasas adicionales, como por ejemplo el estéreo.
Tabla 5: un ejemplo de una cabecera de carga útil RTP para la paquetización con cabecera
Las realizaciones aplican a un códec para una señal de voz/audio. La Figura 6 es un diagrama de bloque esquemático de una aparato según las realizaciones. Esta figura ilustra parte de un lado codificador de un códec. El aparato 600 comprende una unidad 601 de entrada (unidad de recepción) configurada para recibir los datos de carga útil de voz/audio, y una unidad 605 para paquetizar la carga útil de voz/audio para la transmisión como un flujo de bits. El aparato comprende además una unidad 603 para decidir si se usa o no cabecera de carga útil. La Figura 6 ilustra sólo las unidades que son necesarias para entender las realizaciones de la invención. Ya que el aparato 600 se puede implementar como una parte de un codificador, puede haber diversas otras unidades que realicen la codificación de la señal de voz/audio que no se muestren en la figura. Además, la unidad 601 de recepción puede ser vista como una unidad para recibir una señal de voz/audio codificada para paquetización, o puede ser vista como una unidad para recibir una señal de voz/audio, en cuyo caso puede haber una o más unidades entre la unidad 601 de recepción y la unidad 603 de decisión.
La Figura 7 es un diagrama de bloques esquemático de otro aparato de ejemplo según las realizaciones. Esta figura ilustra parte de un lado decodificador del códec. El aparato 700 comprende una unidad 701 de entrada (unidad de recepción) configurada para recibir los paquetes 707 de datos que comprende una señal de voz/audio codificada, y una unidad 703 para despaquetizar los paquetes 707 de datos recibidos para decodificar la señal de voz/audio codificada. La Figura 7 ilustra sólo unidades que son necesarias para entender las realizaciones de la invención. Ya que el aparato 700 se puede implementar como una parte de un decodificador, pueden existir diversas otras unidades que realicen la decodificación de la señal de voz/audio codificada que no se muestren en la Figura 7.
El códec con sus unidades incluidas se podría implementar en hardware. Existen numerosas variantes de elementos de circuito que se pueden usar y combinar para conseguir las funciones de la unidades del códec. Tales variantes son abarcadas por las realizaciones. Ejemplos concretos de implementación hardware del códec es la implementación en
un hardware de procesador de señales digitales (DSP) y en tecnología de circuitos integrados, incluyendo ambas los circuitos electrónicos de propósito general y los circuitos de aplicaciones específicas.
La Figura 8 muestra otro ejemplo de un aparato según las realizaciones. El aparato 800 comprende un nodo 801 de entrada para recibir una señal de voz/audio (cuando el aparato es un decodificador), y un nodo 803 de salida para proporcionar un flujo de bits para su transmisión (codificador) o para proporcionar una señal de voz/audio decodificada (decodificador). El aparato 800 comprende además un procesador 805, por ejemplo una unidad central de procesamiento (CPU), y un producto de programa informático en forma de una memoria 807 para almacenar las instrucciones, por ejemplo el programa 809 informático que, al ser recuperado de la memoria 807 y ejecutado por el procesador 805 provoca que el aparato 800 realice los procesos conectados con las realizaciones de la presente invención, por ejemplo al menos uno de los métodos ilustrados en las Figura 1,2 y 3. El procesador 805 está acoplado de manera comunicativa al nodo 801 de entrada, al nodo 803 de salida y a la memoria 807.
La tecnología descrita anteriormente puede ser usada por ejemplo en un códec de voz/audio, que puede ser usado en un dispositivo móvil (por ejemplo un teléfono móvil, portátil) o una dispositivo fijo, tal como un ordenador personal.
Se ha de entender que la elección de las unidades o módulos de interacción, así como la denominación de las unidades son únicamente con propósito ejemplar, y que pueden ser configuradas en una pluralidad de maneras alternativas para ser capaces de ejecutar las acciones de proceso descritas.
De debería observar también que las unidades o módulos descritos en esta descripción han de ser consideradas como entidades lógicas y no necesariamente como unidades físicas separadas, Se apreciará que el alcance de la tecnología descrita en el presente documento abarca totalmente otras realizaciones que pueden resultar obvias para aquellos expertos en la técnica, y que el alcance de esta descripción por consiguiente no ha de ser limitado.
La referencia a un elemento en singular no está destinada a significar “uno y sólo uno” a menos que se diga explícitamente lo contrario, sino más bien “uno o más”.
En la descripción anterior, con el propósito de la explicación y la no limitación, se exponen detalles específicos tales como arquitecturas, interfaces, técnicas, etc. concretas para proporcionar un conocimiento minucioso de la tecnología descrita. Las realizaciones de la invención son definidas por las reivindicaciones.
En algunos ejemplos, se omiten las descripciones detalladas de dispositivos, circuitos, y métodos bien conocidos para no oscurecer la descripción de la tecnología descrita con detalles innecesarios.
Por tanto, por ejemplo, será apreciado por aquellos expertos en la técnica que las figuras en el presente documento pueden representar vistas conceptuales de circuitos ilustrativos u otras unidades funcionales que realizan los principios de la tecnología, y/o de diversos procesos que pueden ser sustancialmente representados en un medio legible por ordenador y ejecutados por un ordenador o un procesador, incluso aunque dicho ordenador o procesador pueda no haber sido explícitamente mostrado en las figuras.
Las funciones de los diversos elementos incluyendo los bloques funcionales pueden ser proporcionadas a través del uso de hardware tal como hardware de circuito y/o hardware capaz de ejecutar software en forma de instrucciones codificadas almacenadas en un medio legible por ordenador. Por tanto, tales funciones y bloques funcionales ilustrados han de ser entendidos como que son bien implementados en hardware y/o implementados por ordenador, y por tanto implementados por máquina.
Las realizaciones descritas anteriormente han de ser entendidas como unos pocos ejemplos ilustrativos de la presente invención. Será entendido por aquellos expertos en la técnica que se pueden hacer diversas modificaciones, combinaciones y cambios a las realizaciones sin salir del alcance de la presente invención tal como es definido por las reivindicaciones.
En concreto, las diferentes soluciones de partes en las diferentes realizaciones se pueden combinar en otras configuraciones, donde sea técnicamente posible.
Claims (23)
1. Un método para dar formato a una carga útil para la transmisión de datos de códec de voz multimodo o datos de códec de audio multimodo, comprendiendo el método:
- decidir (103) en base a un modo de códec y una tasa de bits si se usa un formato de carga útil con cabecera o sin cabecera, en donde si se usa el formato de carga útil con cabecera con una cabecera de carga útil la cabecera de la carga útil comprende información de señalización, en donde la información de señalización se asocia con al menos uno de entre: una identificación de modo de códec, una tasa de bits, una adaptación de modo, una solicitud de modo de códec, un ancho de banda de audio, un modo interno de códec y la agregación de tramas; y
- paquetizar (105) unos datos de carga útil RTP con o sin la cabecera de carga útil dependiendo de la decisión.
2. El método según la reivindicación 1, en donde el formato de carga útil sin cabecera se asocia con tamaños de carga útil protegidos que identifican de manera unívoca los modos y las tasas de bits de códec.
3. El método según la reivindicación 1 o 2, en donde los datos de carga útil RTP transportan una trama codificada única cuando se usa el formato de carga única sin cabecera.
4. El método según la reivindicación 1, en donde se decide usar el formato con cabecera cuando se usa agregación de tramas con múltiples tramas codificadas por paquetes.
5. El método según la reivindicación 1, en donde la funcionalidad requerida comprende al menos uno de:
- agregación de tramas donde los datos de carga útil de un paquete se asocien con múltiples tramas - una inclusión de una cabecera de carga útil RTP;
- una inclusión de datos de modo de adaptación; y
- una inclusión de datos de señalización específicos.
6. El método según la reivindicación 5, en donde se decide usar el formato con cabecera cuando se incluyen datos de señalización específicos de códec.
7. El método según la reivindicación 6, en donde los datos de señalización específicos de códec comprenden la información de ancho de banda de audio o la información de modo interno de códec.
8. El método según la reivindicación 5, en donde se decide usar el formato con cabecera cuando se incluyen los bits de información relacionados con la adaptación del modo de códec.
9. El método según la reivindicación 1, en donde la funcionalidad requerida comprende la transmisión de información de señalización extra asociada con el modo de códec a ser usado para interoperar con el equipo heredado.
10. El método según la reivindicación 9, en donde dicha información de señalización extra se relaciona con la adaptación del modo de códec y comprende bits CMR, Solicitud de Modo de Códec, en donde se permite solicitar un subconjunto de modos al usar el formato de carga útil sin cabecera, y las CMR para los modos que no pertenecen a dicho subconjunto de modos se transmiten usando el formato de carga útil con cabecera.
11. El método según la reivindicación 2, en donde cuando se decide usar el formato de carga útil con cabecera, el tamaño de paquete es ajustado añadiendo bytes de relleno de manera que no coincida con ninguno de los tamaños de carga útil protegidos.
12. Un método para despaquetizar un paquete RTP recibido de tramas de datos de voz multimodo codificadas o de tramas de datos de audio multimodo codificadas, comprendiendo el método:
- determinar (301) si un tamaño de carga útil del paquete recibido corresponde a cualquiera de los miembros de un conjunto de tamaños de carga útil sin cabecera protegidos que identifican de manera unívoca los modos y las tasas de bits de códec, y
- leer (305) una cabecera de carga útil si se determina que el tamaño de carga útil del paquete recibido no corresponde a ninguno de los miembros del conjunto de tamaños de carga útil protegidos.
13. El método según la reivindicación 12, que comprende además extraer la información de la cabecera de carga útil para determinar un modo de códec y una tasa de bits, cuando se determina que el tamaño de carga útil del paquete recibido no corresponde a ninguno de los miembros del conjunto de tamaños de carga útil protegidos.
14. El método según la reivindicación 12, que comprende además determinar un modo de códec y una tasa de bits con base en el tamaño (303) de carga útil, cuando se determina que el tamaño de carga útil del paquete recibido corresponde a uno de los miembros del conjunto de tamaños de carga útil protegidos.
15. Un aparato para dar formato a una carga útil para la transmisión de datos de códec de voz multimodo o datos de códec de audio multimodo, comprendiendo el aparato:
un procesador (805), y
una memoria (807) que almacena instrucciones (809), que al ser ejecutadas por el procesador, provocan que el aparato:
- decida con base en un modo de códec y una tasa de bits si se usa un formato de carga útil con cabecera o sin cabecera, en donde si se usa el formato de carga útil con cabecera con una cabecera de carga útil la cabecera de carga útil comprende información de señalización, en donde la información de señalización se asocia con al menos uno de entre: una identificación de modo de códec, una tasa de bits, una adaptación de modo, una solicitud de modo de códec, un ancho de banda de audio, un modo interno de códec y la agregación de tramas; y
- paquetice unos datos de carga útil RTP con o sin la cabecera de carga útil dependiendo de la decisión.
16. El aparato según la reivindicación 15, que comprende además la memoria que almacena instrucciones que, al ser ejecutadas por el procesador, provocan que el aparato realice el método según cualquiera de las reivindicaciones 2 a 14.
17. Un aparato para despaquetizar un paquete RTP recibido de tramas de datos de voz multimodo codificadas o de tramas de datos de audio multimodo codificadas que comprende:
un procesador (805)
una memoria (807) que almacena instrucciones (809), que al ser ejecutadas por el procesador, provocan que el aparato:
- reciba un paquete de datos que comprende una señal de voz codificada o una señal de audio codificada;
- determine si un tamaño de carga útil del paquete recibido corresponde a alguno de los miembros de un conjunto de tamaños de carga útil sin cabecera protegidos que identifican de manera unívoca los modos y las tasas de bits de códec, y
- lea una cabecera de carga útil si se determina que el tamaño de carga útil del paquete recibido no corresponde con ninguno de los miembros del conjunto de tamaños de carga útil protegidos.
18. El aparato según la reivindicación 17, que comprende además
- extraer información de la cabecera de carga útil para determinar un modo de códec y una tasa de bits, si se determina que el tamaño de carga útil del paquete recibido no corresponde con ninguno de los miembros del conjunto de tamaños de carga útil protegidos, y
- determinar un modo de códec y una tasa de bits con base en el tamaño de carga útil, si se determina que el tamaño de carga útil del paquete recibido corresponde a uno de los miembros del conjunto de tamaños de carga útil protegidos.
19. El aparato según cualquiera de las reivindicaciones 15 a 18, en donde el aparato está comprendido en o está acoplado de manera comunicativa con un códec de voz o audio que tiene al menos dos modos operativos de los que al menos uno es un modo de interoperabilidad interoperable con un códec heredado.
20. El aparato según cualquiera de las reivindicaciones 15 a 19, en donde el aparato está comprendido en un dispositivo móvil.
21. Un programa (809) informático que comprende unidades de código legibles por ordenador que al ser ejecutadas en un aparato provocan que el aparato:
- decida con base en un modo de códec y una tasa de bits si se usa un formato de carga útil con cabecera o sin cabecera, en donde si se usa el formato de carga útil con cabecera con una cabecera de carga útil la cabecera de carga útil comprende información de señalización, en donde la información de señalización se asocia con al menos uno de entre: una identificación de modo de códec, una tasa de bits, una adaptación de modo, una solicitud de modo de códec, un ancho de banda de audio, un modo interno de códec y la agregación de tramas; y
- paquetice unos datos de carga útil RTP con o sin la cabecera de carga útil dependiendo de la decisión.
22. Un programa (809) informático que comprende unidades de código legibles por ordenador que al ejecutarse en un aparato provocan que el aparato:
- reciba un paquete de datos que comprende una señal de voz multimodo codificada o una señal de audio multimodo codificada;
- determine si un tamaño de carga útil del paquete recibido corresponde a alguno de los miembros de un conjunto de tamaños de carga útil sin cabecera protegidos que identifican de manera unívoca los modos de códec y las tasas de bits, y
- lea una cabecera de carga útil si se determina que el tamaño de carga útil del paquete recibido no corresponde con ninguno de los miembros del conjunto de tamaños de carga útil protegidos.
23. Un producto (807) de programa informático, que comprende un medio legible por ordenador y un programa (809) informático según la reivindicación 21 o 22 almacenado en el medio legible por ordenador.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361909748P | 2013-11-27 | 2013-11-27 | |
PCT/SE2014/051412 WO2015080658A1 (en) | 2013-11-27 | 2014-11-27 | Hybrid rtp payload format |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2890653T3 true ES2890653T3 (es) | 2022-01-21 |
Family
ID=52293138
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES14824574T Active ES2890653T3 (es) | 2013-11-27 | 2014-11-27 | Formato de carga útil RTP híbrido |
ES21186801T Active ES2929903T3 (es) | 2013-11-27 | 2014-11-27 | Formato de carga útil RTP híbrido |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES21186801T Active ES2929903T3 (es) | 2013-11-27 | 2014-11-27 | Formato de carga útil RTP híbrido |
Country Status (6)
Country | Link |
---|---|
US (4) | US10121483B2 (es) |
EP (2) | EP3075132B1 (es) |
ES (2) | ES2890653T3 (es) |
PL (1) | PL3075132T3 (es) |
RU (2) | RU2661762C2 (es) |
WO (1) | WO2015080658A1 (es) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
RU2661762C2 (ru) * | 2013-11-27 | 2018-07-19 | Телефонактиеболагет Л М Эрикссон (Пабл) | Гибридный формат полезной нагрузки rtp |
CN105357172A (zh) * | 2014-08-21 | 2016-02-24 | 中兴通讯股份有限公司 | 数据报文的传输处理方法及装置 |
US20160323425A1 (en) * | 2015-04-29 | 2016-11-03 | Qualcomm Incorporated | Enhanced voice services (evs) in 3gpp2 network |
JP2019506094A (ja) * | 2016-02-18 | 2019-02-28 | ルネサスエレクトロニクス株式会社 | メッセージハンドラ |
US10057393B2 (en) * | 2016-04-05 | 2018-08-21 | T-Mobile Usa, Inc. | Codec-specific radio link adaptation |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5745523A (en) * | 1992-10-27 | 1998-04-28 | Ericsson Inc. | Multi-mode signal processing |
US6233253B1 (en) * | 1997-05-23 | 2001-05-15 | Thomson Licensing S.A. | System for digital data format conversion and bit stream generation |
US6680955B1 (en) * | 1999-08-20 | 2004-01-20 | Nokia Networks Oy | Technique for compressing a header field in a data packet |
US7688745B1 (en) * | 2000-08-14 | 2010-03-30 | Nokia Siemens Networks Oy | Communication system and method providing a mode selection procedure |
US20020064164A1 (en) * | 2000-10-06 | 2002-05-30 | Barany Peter A. | Protocol header construction and/or removal for messages in wireless communications |
DE60131890T2 (de) * | 2000-10-11 | 2008-12-11 | Broadcom Corp., Irvine | Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung |
US7136395B2 (en) * | 2000-11-30 | 2006-11-14 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for transmission of headerless data packets over a wireless link |
US7305043B2 (en) * | 2002-10-17 | 2007-12-04 | Ibiquity Digital Corporation | Method and apparatus for formatting signals for digital audio broadcasting transmission and reception |
US7908399B2 (en) * | 2003-05-30 | 2011-03-15 | Cisco Technology, Inc. | Compression of repeated patterns in full bandwidth channels over a packet network |
US20050261899A1 (en) * | 2004-05-19 | 2005-11-24 | Stefan Brueck | Methods of improving capacity for voice users in a communication network |
US7656870B2 (en) * | 2004-06-29 | 2010-02-02 | Damaka, Inc. | System and method for peer-to-peer hybrid communications |
US7463901B2 (en) * | 2004-08-13 | 2008-12-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Interoperability for wireless user devices with different speech processing formats |
US20060262788A1 (en) * | 2005-05-23 | 2006-11-23 | Broadcom Corporation | Dynamic payload header suppression extensions for IPV6 |
JP4645856B2 (ja) * | 2005-10-06 | 2011-03-09 | 日本電気株式会社 | パケット交換網−回線交換網間のメディア通信におけるプロトコル変換システム |
DE112006002644T5 (de) | 2005-10-07 | 2008-09-18 | Agere Systems, Inc. | Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse |
US20070086434A1 (en) * | 2005-10-19 | 2007-04-19 | Muthaiah Venkatachalam | Efficient mechanisms for supporting VoIp in a wireless network |
WO2008021182A2 (en) | 2006-08-09 | 2008-02-21 | Interdigital Technology Corporation | Method and apparatus for providing differentiated quality of service for packets in a particular flow |
US8155090B2 (en) * | 2007-11-01 | 2012-04-10 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for efficient multimedia delivery in a wireless packet network |
US8422373B2 (en) * | 2008-01-17 | 2013-04-16 | Nokia Corporation | Adaptive multi-rate codec bit rate control in a wireless system |
US8355336B2 (en) * | 2008-02-13 | 2013-01-15 | Qualcomm Incorporated | Methods and apparatus for formatting headers in a communication frame |
US9454973B2 (en) | 2009-04-07 | 2016-09-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for providing a backwards compatible payload format |
US9401975B2 (en) * | 2010-11-10 | 2016-07-26 | Panasonic Intellectual Property Corporation Of America | Terminal and codec mode selection method |
RU2459373C1 (ru) * | 2010-12-15 | 2012-08-20 | Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) | Способ определения длины кадра передачи кодеков речевых сигналов на основе линейного предсказания в сетях с пакетной коммутацией на основе ip-протокола |
RU2661762C2 (ru) * | 2013-11-27 | 2018-07-19 | Телефонактиеболагет Л М Эрикссон (Пабл) | Гибридный формат полезной нагрузки rtp |
-
2014
- 2014-11-27 RU RU2016125218A patent/RU2661762C2/ru active
- 2014-11-27 PL PL14824574T patent/PL3075132T3/pl unknown
- 2014-11-27 ES ES14824574T patent/ES2890653T3/es active Active
- 2014-11-27 RU RU2018123560A patent/RU2766274C2/ru active
- 2014-11-27 US US15/039,678 patent/US10121483B2/en active Active
- 2014-11-27 WO PCT/SE2014/051412 patent/WO2015080658A1/en active Application Filing
- 2014-11-27 ES ES21186801T patent/ES2929903T3/es active Active
- 2014-11-27 EP EP14824574.9A patent/EP3075132B1/en active Active
- 2014-11-27 EP EP21186801.3A patent/EP3917112B1/en active Active
-
2018
- 2018-08-21 US US16/107,356 patent/US10242686B2/en active Active
-
2019
- 2019-03-14 US US16/353,748 patent/US10535359B2/en active Active
- 2019-12-26 US US16/727,423 patent/US10930294B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
RU2766274C2 (ru) | 2022-02-10 |
EP3917112A1 (en) | 2021-12-01 |
ES2929903T3 (es) | 2022-12-02 |
US20200135222A1 (en) | 2020-04-30 |
RU2018123560A (ru) | 2019-03-06 |
RU2018123560A3 (es) | 2021-10-08 |
US20190005975A1 (en) | 2019-01-03 |
RU2661762C2 (ru) | 2018-07-19 |
US10242686B2 (en) | 2019-03-26 |
PL3075132T3 (pl) | 2022-01-17 |
US20160379658A1 (en) | 2016-12-29 |
US10535359B2 (en) | 2020-01-14 |
US10121483B2 (en) | 2018-11-06 |
EP3075132B1 (en) | 2021-08-18 |
US10930294B2 (en) | 2021-02-23 |
EP3075132A1 (en) | 2016-10-05 |
US20190214032A1 (en) | 2019-07-11 |
WO2015080658A1 (en) | 2015-06-04 |
EP3917112B1 (en) | 2022-10-05 |
RU2016125218A (ru) | 2018-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2890653T3 (es) | Formato de carga útil RTP híbrido | |
ES2749222T3 (es) | Terminal y procedimiento de selección de modo de codificación | |
US8873545B2 (en) | Gateway apparatus, system and method | |
US9454973B2 (en) | Method and arrangement for providing a backwards compatible payload format | |
ES2730709T3 (es) | Mecanismo para la señalización dinámica de las capacidades del codificador | |
ES2958212T3 (es) | Señalización de una solicitud de adaptación de una sesión de comunicación de voz sobre IP | |
BRPI0619451A2 (pt) | método para proporcionar tráfego de plano de usuário durante um estado de plano de usuário inativo de uma conexão em uma rede de acesso; produto de programa de computador; dispositivo de transmissão para proporcionar tráfego de plano de usuário durante um estado de plano de usuário inativo de uma conexão em uma rede de acesso; dispositivo de terminal para proporcionar comunicação através de uma rede de acesso; e dispositivo controlador de rede para proporcionar comunicação através de uma rede de acesso | |
US20140233616A1 (en) | Communication system and method | |
ES2610575T3 (es) | Interoperación eficaz entre servicios multimedia conmutados por circuitos y conmutados por paquetes | |
JP5459309B2 (ja) | ゲートウェイ装置と方法と通信システム | |
WO2008086748A1 (en) | A-interface-based mobile communication method,system and equipment | |
ES2790598T3 (es) | Comunicación en un sistema que tiene diferentes calidades de datos de usuario | |
ES2557309T3 (es) | Uso de un nodo pasarela de medios común y un códec coordinado por un nodo de control de llamadas de origen y uno de terminación | |
ES2881704T3 (es) | Dispositivo de red de gestión | |
WO2019131498A1 (ja) | 端末装置、方法、および、集積回路 | |
WO2018018475A1 (zh) | 一种最大打包间隔的协商方法、装置以及存储介质 |