21 May
2019
21 May
'19
6:48 p.m.
Hi,
I want to implement selective transcoding, e.g. avoiding Transcoding
between a HD codec (G722) and a non HD Codec (G711).
In case the caller does offer HD codecs, this is fine, e.g.
if(sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_offer("codec-transcode=OPUS codec-transcode=G722
codec-transcode=PCMA");
} else {
rtpengine_manage("codec-transcode=PCMA");
}
Now I have the issue, if the callee only sends me G711, I don't want to
offer G722 or Opus to the caller. However, rtpengine_answer() does not seem
to accept "codec-strip=G722 codec-strip=OPUS", e.g.:
onreply_route() {
if(!sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
}
}
As a result, the SDP always contains the transcoding options, e.g. G722 and
OPUS. I always end up in transcoding G722 to G711, which is meaningless in
that case.
Any ideas on how to solve that?
(above examples very simplified)
Thanks,
Carsten
--
Carsten Bock I Managing Director
ng-voice GmbH
Millerntorplatz 1 I 20359 Hamburg I Germany
www.ng-voice.com
Mobile +49 (0)179-20 21 244 I Direct +49 (0)40-52 47 593-40 I Fax +49
(0)40-52 47 593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock, Dr. David Bachmann
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
22 May
22 May
12:37 a.m.
On 21/05/2019 11.48, Carsten Bock wrote:
Hi,
I want to implement selective transcoding, e.g. avoiding Transcoding
between a HD codec (G722) and a non HD Codec (G711).
In case the caller does offer HD codecs, this is fine, e.g.
if(sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_offer("codec-transcode=OPUS codec-transcode=G722
codec-transcode=PCMA");
} else {
rtpengine_manage("codec-transcode=PCMA");
}
Now I have the issue, if the callee only sends me G711, I don't want
to offer G722 or Opus to the caller. However, rtpengine_answer() does
not seem to accept "codec-strip=G722 codec-strip=OPUS", e.g.:
onreply_route() {
if(!sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
}
}
As a result, the SDP always contains the transcoding options, e.g.
G722 and OPUS. I always end up in transcoding G722 to G711, which is
meaningless in that case.
Any ideas on how to solve that?
(above examples very simplified)
All transcoding options must be present in the `offer` - they're ignored
in the `answer`. (At least in newer versions - older versions did accept
them in an `answer`, but they didn't do what was expected, which is why
they were removed in later versions.)
The reason for this is that the callee may send media before the SDP
from the callee (the answer) is seen. Therefore all transcoding
decisions must be made at the time of the offer (otherwise you may end
up switching codecs whenever the answer is seen, which is undesirable).
So you'll have to figure out a way to decide what you want to do based
on what you know at the time of the offer.
I'm a bit confused by your example. If you want to avoid transcoding
between G.722 or Opus, and G.711, why do you want to offer PCMA when the
caller supports G.722 or Opus? Shouldn't you rather only offer other
"HD" codecs and strip all non-HD codecs in that case?
Cheers
1:42 a.m.
Hi Richard,
Thanks for your reply, understood.
The issue is following (not really an issue, more an optimization):
At the moment of the offer, I simply don't know, what will be supported by
the callee. G711 is however always supported, that's why I don't want to
strip it. I send the call to our upstream provider; if he sends it to
Telefonica, we get an answer with G722 and G711. If he sends it to Deutsche
Telekom, the answer is only G711. However, we don't know, if it's gonna be
Telefonica or Deutsche Telekom...
I was thinking about avoiding uneccessary RTP traffic (in HD) between
RTPEngine and the device in case of an outbound call. From a signalling
perspective, I get the right result, if I use sdp_remove_codecs() in my
reply. However, that won't work, since the RTP stream sent from RTPEngine
to the device is in HD, regardless of the signalling.
I can live with the status quo.
Thanks again,
Carsten
Richard Fuchs <rfuchs(a)sipwise.com> schrieb am Di., 21. Mai 2019, 23:38:
On 21/05/2019 11.48, Carsten Bock wrote:
Hi,
I want to implement selective transcoding, e.g. avoiding Transcoding
between a HD codec (G722) and a non HD Codec (G711).
In case the caller does offer HD codecs, this is fine, e.g.
if(sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_offer("codec-transcode=OPUS codec-transcode=G722
codec-transcode=PCMA");
} else {
rtpengine_manage("codec-transcode=PCMA");
}
Now I have the issue, if the callee only sends me G711, I don't want
to offer G722 or Opus to the caller. However, rtpengine_answer() does
not seem to accept "codec-strip=G722 codec-strip=OPUS", e.g.:
onreply_route() {
if(!sdp_with_codecs_by_name("G722,OPUS")) {
rtpengine_ manage("codec-strip=OPUS codec-strip=G722");
}
}
As a result, the SDP always contains the transcoding options, e.g.
G722 and OPUS. I always end up in transcoding G722 to G711, which is
meaningless in that case.
Any ideas on how to solve that?
(above examples very simplified)
All transcoding options must be present in the `offer` - they're ignored
in the `answer`. (At least in newer versions - older versions did accept
them in an `answer`, but they didn't do what was expected, which is why
they were removed in later versions.)
The reason for this is that the callee may send media before the SDP
from the callee (the answer) is seen. Therefore all transcoding
decisions must be made at the time of the offer (otherwise you may end
up switching codecs whenever the answer is seen, which is undesirable).
So you'll have to figure out a way to decide what you want to do based
on what you know at the time of the offer.
I'm a bit confused by your example. If you want to avoid transcoding
between G.722 or Opus, and G.711, why do you want to offer PCMA when the
caller supports G.722 or Opus? Shouldn't you rather only offer other
"HD" codecs and strip all non-HD codecs in that case?
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:16 a.m.
On 21/05/2019 18.42, Carsten Bock wrote:
Hi Richard,
Thanks for your reply, understood.
The issue is following (not really an issue, more an optimization):
At the moment of the offer, I simply don't know, what will be
supported by the callee. G711 is however always supported, that's why
I don't want to strip it. I send the call to our upstream provider; if
he sends it to Telefonica, we get an answer with G722 and G711. If he
sends it to Deutsche Telekom, the answer is only G711. However, we
don't know, if it's gonna be Telefonica or Deutsche Telekom...
I was thinking about avoiding uneccessary RTP traffic (in HD) between
RTPEngine and the device in case of an outbound call. From a
signalling perspective, I get the right result, if I use
sdp_remove_codecs() in my reply. However, that won't work, since the
RTP stream sent from RTPEngine to the device is in HD, regardless of
the signalling.
Maybe you want to make your transcoding options also dependent on
whether G.711 was present in the original offer, and/or in what order
the codecs were listed? Rtpengine won't do transcoding if both sides
support the same codec, even if other codec pairings are possible
(unless `always-transcode` is given). Are you using that option? Are you
using other options to reorder codecs in the offer? Because normally the
first supported codec will be used, and rtpengine adds transcoding codec
offers to the end of the list. So they should only be used if no other
codec is supported by the callee, unless the callee ignores the listed
codec preferences, or codecs were reordered, or `always-transcode` was used.
Cheers
29 May
29 May
10:25 a.m.
Hi,
the problem is, the device (a VoLTE phone) will ALWAYS offer AMR-WB and
AMR-NB and we will need to do transcoding to G722 / G711 in most cases
(unless the B-Party actually offers AMR-WB/AMR-NB).
The Answer may be pure G711 (RTPEngine will do Transcoding G711 <=> AMR-WB
[meaningless]) or G722 (RTPEngine will do Transcoding G722 <=> AMR-WB
[Makes sense]) or AMR-NB/-WB (no Transcoding [ideal]). If I could limit the
Answer from RTPEngine to contain only AMR-NB, that would ideal, as AMR-NB
has less complexity, than transcoding into AMR-WB and it would additionally
save bandwidth (which is important in our case).
However, I should mention that I am already more than happy with the
current result. Transcoding is working great, even with AMR/AMR-WB!
Thanks,
Carsten
--
Carsten Bock I Managing Director
ng-voice GmbH
Millerntorplatz 1 I 20359 Hamburg I Germany
www.ng-voice.com
Mobile +49 (0)179-20 21 244 I Direct +49 (0)40-52 47 593-40 I Fax +49
(0)40-52 47 593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock, Dr. David Bachmann
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
Am Mi., 22. Mai 2019 um 01:17 Uhr schrieb Richard Fuchs <rfuchs(a)sipwise.com
:
On 21/05/2019 18.42, Carsten Bock wrote:
Hi Richard,
Thanks for your reply, understood.
The issue is following (not really an issue, more an optimization):
At the moment of the offer, I simply don't know, what will be
supported by the callee. G711 is however always supported, that's why
I don't want to strip it. I send the call to our upstream provider; if
he sends it to Telefonica, we get an answer with G722 and G711. If he
sends it to Deutsche Telekom, the answer is only G711. However, we
don't know, if it's gonna be Telefonica or Deutsche Telekom...
I was thinking about avoiding uneccessary RTP traffic (in HD) between
RTPEngine and the device in case of an outbound call. From a
signalling perspective, I get the right result, if I use
sdp_remove_codecs() in my reply. However, that won't work, since the
RTP stream sent from RTPEngine to the device is in HD, regardless of
the signalling.
Maybe you want to make your transcoding options also dependent on
whether G.711 was present in the original offer, and/or in what order
the codecs were listed? Rtpengine won't do transcoding if both sides
support the same codec, even if other codec pairings are possible
(unless `always-transcode` is given). Are you using that option? Are you
using other options to reorder codecs in the offer? Because normally the
first supported codec will be used, and rtpengine adds transcoding codec
offers to the end of the list. So they should only be used if no other
codec is supported by the callee, unless the callee ignores the listed
codec preferences, or codecs were reordered, or `always-transcode` was
used.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:08 p.m.
On 29/05/2019 03.25, Carsten Bock wrote:
Hi,
the problem is, the device (a VoLTE phone) will ALWAYS offer AMR-WB
and AMR-NB and we will need to do transcoding to G722 / G711 in most
cases (unless the B-Party actually offers AMR-WB/AMR-NB).
The Answer may be pure G711 (RTPEngine will do Transcoding G711 <=>
AMR-WB [meaningless]) or G722 (RTPEngine will do Transcoding G722 <=>
AMR-WB [Makes sense]) or AMR-NB/-WB (no Transcoding [ideal]). If I
could limit the Answer from RTPEngine to contain only AMR-NB, that
would ideal, as AMR-NB has less complexity, than transcoding into
AMR-WB and it would additionally save bandwidth (which is important in
our case).
Ah I see. As explained already, making this decision at the time the
answer comes through doesn't really work, because the codec in question
might already be in use at that time. What you would like to see instead
is to make a decision at the time of the offer: Transcode one of the
offered transcoded codecs to a particular one of the original offered
codecs ("offer G.722 and transcode to AMR-WB"), and transcode another
offered transcoded codec to another one of the original offered codecs
("offer G.711 and transcode to AMR-NB"). Something along those lines,
correct? That's simply a feature that doesn't yet exist, as right now
transcoding always happens to the first supported original codec (i.e.
if AMR-WB is first in the list, then that's what will be used).
Cheers
2004
days inactive
2012
days old
5 comments
2 participants
participants (2)
-
Carsten Bock -
Richard Fuchs