Fritz Box Fon: G.729 compatible with SIPDiscount/Voipbuster?

[maleas]

Hello everybody,

please first pardon my English, I do not speak German unfortunately

I live at Greece and have an Annex A Fritz Box Fon, with the English firmware 06.04.02. I am also using 2 VoIP providers, SIPDiscount and i-Call (a greek one).

With i-Call my Fritz can succesfully make calls using G.729. I can see that by telnet'ing to my fbf. However, with SIPDiscount if I enable on fbf only G.729 and iLBC*, I receive an "Unsupported media type (415)" error.

So the question I want to make is this: has anyone been able to make G.729 calls using Fritz!Box Fon over SIPDiscount and/or VoIPBuster?

Thanks in advance for any info provided.


*=To enable only G.729 and iLBC, I modified /var/flash/voip.cfg to the following values:

/var/flash/voip.cfg
        use_audiocodecs = yes;
        audiocodecs = "G729", "iLBC";
        verbose = yes;
        sip_prio = 0;
        rtp_prio = 0;
        dyn_codecs = no;
        prio_low_codec = no;

You can read the full discussion at [thread]107053[/thread].

 

[maleas]

Some background info on G.729

Motivated by some info I received here about "different" G.729 implementations, I'd like to present some info here as to which is what of G.729. I assume all of this is known by most of you, but in any case some boring tech info would not be a problem I guess

From RFC3551:

[...]

4.5.6 G729

G729 is specified in ITU-T Recommendation G.729, "Coding of speech at
8 kbit/s using conjugate structure-algebraic code excited linear
prediction (CS-ACELP)". A reduced-complexity version of the G.729
algorithm is specified in Annex A to Rec. G.729. The speech coding
algorithms in the main body of G.729 and in G.729 Annex A are fully
interoperable with each other, so there is no need to further
distinguish between them. An implementation that signals or accepts
use of G729 payload format may implement either G.729 or G.729A
unless restricted by additional signaling specified elsewhere related
specifically to the encoding rather than the payload format. The
G.729 and G.729 Annex A codecs were optimized to represent speech
with high quality, where G.729 Annex A trades some speech quality for
an approximate 50% complexity reduction [10]. See the next Section
(4.5.7) for other data rates added in later G.729 Annexes. For all
data rates, the sampling frequency (and RTP timestamp clock rate) is
8,000 Hz.

A voice activity detector (VAD) and comfort noise generator (CNG)
algorithm in Annex B of G.729 is RECOMMENDED for digital simultaneous
voice and data applications and can be used in conjunction with G.729
or G.729 Annex A. A G.729 or G.729 Annex A frame contains 10 octets,
while the G.729 Annex B comfort noise frame occupies 2 octets.

What the previous paragraphs say in plain words is that:
* G.729 has quite a few variants: there's G.729 and there's G.729 Annex A (version compatible to G.729, albeit of lower computation complexity)
* To make things more complex, a G.729 or G.729 Annex A coder may optionally implement VAD and CNG, per "G.729 specification Annex B".

Therefore we have the following:

• A G.729 encoder/decoder that can speak to either G.729 or G.729 Annex A decoders/encoders.
• A G.729 Annex A encoder/decoder that can speak to either G.729 or G.729 Annex A encoders/decoders
• A G.729 encoder/decoder that also conforms to Annex B. In this case, if this encoder
  • is forced to use Annex B features, it can talk to only G.729 Annex B or G.729 Annex _and_ Annex B encoders
  • is not forced to use Annex B features, it can talk to _any_ G.729 encoders

From the same RFC:

Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. he MIME registration for G729 in RFC
3555 [7] specifies a parameter that MAY be used with MIME or SDP to
restrict the use of comfort noise frames.

Additionally, from RFC3555

4.1.9. Registration of MIME media type audio/G729

MIME media type name: audio

MIME subtype name: G729

Required parameters: None

Optional parameters:
ptime, maxptime

annexb: indicates that Annex B, voice activity detection, is
used or preferred. Permissible values are "yes" and "no"
(without the quotes); "yes" is implied if this parameter is
omitted.

To cut a long-story short: Fritz Box Fon with English firmware 06.04.02 does have a G.729 implementation. This implementation can be used to make calls using specific providers. The question here is why it doesn't work with SIPDiscount (although I can not confirm this, noone has posted here). Since I am receiving SIP Error 415 from SIPDiscount, when I'm forcing use of G.729 on fbf, this error tells:

21.4.13 415 Unsupported Media Type

The server is refusing to service the request because the message
body of the request is in a format not supported by the server for
the requested method. The server MUST return a list of acceptable
formats using the Accept, Accept-Encoding, or Accept-Language header
field, depending on the specific problem with the content. UAC
processing of this response is described in Section 8.1.3.5.

Some theories:
* Fritz implementation of G.729 does not support Annex B, whereas the relevant SIPDiscount implementation needs it. Hence for the incompatibility.
* Fritz G.729 is Annex B compliant so in the SIP message to SIPDiscount it sets annexb to "yes" (or omits annexb altogether, meaning that annexb behaviour is wanted), but SIPDiscount G.729 is not Annex B compliant.

Don't really know what is wrong here. I would definitely like to have a packet sniffer to check traffic between the fbf and the internet to check out what exactly it is sending receiving.

 

[gandalf94305]

Try Ethereal: http://www.ethereal.com/ ;-)

I would also be interested in the results...

--gandalf.

PS: I could, of course, check it with my FBF and sipdiscount account as well, but that requires time I don't have presently.

 

[maleas]

Try Ethereal: http://www.ethereal.com/ ;-)

I would also be interested in the results...

lol, thx for the pointer, I do know ethereal, problem is that I have a switch at home, so it would be pointless to try and sniff SIP traffic from/to fbf unfortunately :/

PS: I could, of course, check it with my FBF and sipdiscount account as well, but that requires time I don't have presently.

Well, I did create an issue in AVM's helpdesk and also contacted SIPDiscount support for this matter. Will keep ya posted though

 

[maleas]

*BUMP*

I've opened a ticket for this with AVM, but I have not received a confirmation of this behaviour yet.

So, I'm wondering whether someone could perform the above-mentioned test, to rule out the possibility of my own box being broken (highly unlikely, but still have to check)

 

[philk]

I do know ethereal, problem is that I have a switch at home, so it would be pointless to try and sniff SIP traffic from/to fbf unfortunately :/

There is a very easy way to capture packets in ethereal format on my fritz!box. It's built in! Try

http://fritz.box/html/capture.html

Hope this can help you

 

[maleas]

[Fullquote of philk removed. Can't you read what's just one article up? @philk is sufficient. --gandalf.]

OMG!!!!! Is there anything this little box can't???? Thx a million for the info, this works great!!! Time for some SDP debugging. Will be back with more info.

 

[maleas]

Ok, what I've found so far:

1) There seems to be a definite bug with regard to G.726-32. Specifically, Fritz sends the following SDP message:

[...]
m: audio 7078 RTP/AVP [B]2 102[/B] 100 99 97 18 8 0 101
a: sendrecv
a: rtpmap [B]2[/B] G726-32/8000
a: rtpmap [B]102[/B] G726-32/8000
[...]

Notice the bold "2" and "102" which is the payload type. According to RFC3551, Section 6:

[...]
Payload type 2 was assigned to G721 in
RFC 1890 and to its equivalent successor G726-32 in draft versions of
this specification, but its use is now deprecated and that static
payload type is marked reserved due to conflicting use for the
payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4).

In plain words this means that at some time in RFC1890, payload type 2 was once used to indicate codec G726-32. However, RFC1890 was obsoleted by document RFC3551. The last one also designates payload type 2 to be reserved! Therefore it can not be used to indicate ANY payload. Instead, G726-32 payload must be indicated by a number > 97 (as a dynamic payload type). This is a required behavior, since RFC3551 is also an IETF Internet STANDARD (STD0065).

Instead, Fritz trying to be compatible to the previous RFC1890, designates its G726-32 capability by using both codec type 2 as well as a "user-defined" type 102 for the same codec. To be correct per RFC3551 it should only use codec type 102 as per below:

[...]
m: audio 7078 RTP/AVP [B]102[/B] 100 99 97 18 8 0 101
a: sendrecv
a: rtpmap [B]102[/B] G726-32/8000
[...]

2) G.729 behaviour seems to be per Annex B. That is, in the SDP message sent from fritz, the "annexb" parameter is not set. Therefore, the default is selected, which means that Fritz does want to communicate using Annex B. This does seem like a bug though, since VAD in web admin (Telephony -> Internet Telephony -> Advanced Settings) is not checked. Therefore, the SDP message should include an "annexb=no" line.

Apart from above, everything seems ok with G.729 which is very strange...

 

[maleas]

Problem found

Found the problem finally, it's a SIPDiscount (and possibly Voipbuster) issue!

I contacted SIPDiscount support and sent them the following message:

I have a Fritz Box Fon running the latest firmware. I have tried to configure the fritz to have only G.729 and iLBC as the active codecs. When I do so, it is *impossible* to make calls over SIPDiscount. It tried to do this with voipbuster as well as a test. The same problem appeared.

According to a packet trace I took, the fritz sends the following SDP information:

v=0
o=user YY YY IN IP4 XX.XX.XX.XX
s=call
c=IN IP4 XX.XX.XX.XX
t=1212147183 1212150783
m=audio 7078 RTP/AVP 18 97
a=sendrecv
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtcp:7079

I know that SIPDiscount does not provide iLBC voice (I use the iLBC codec for other p2p voip providers). BUT, G.729 *should* be possible!

Instead, the SIPDiscount server responds with a 415 error. So there, seems to be some incompatibility between Fritz and SIPDiscount, however I'm not sure who's to blame here.

I've registered a ticket with AVM (Fritz manufacturer) but it seems that from your side a check should be made, in case this problem is from your side.

And the reply:

Hi,

I'm working on this problem. The reason why we don't select the G729 codec is because the a=rtpmap:18 is missing in the sdp. We are working to fix this problem. Give me a few day's to fix and update the servers. I will send you a mail when it is fixed, so you can test it.

This is what most likely happened (in more words): RFC3264 states that:

In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings.

So SIPDiscount saw this line and interpreted it such that when a SIP device like fritz sends an SDP message mentioning G.729 (codec payload type 18 in the "m" line above) but no a=rtpmap:18 line, the specific codec was rejected. So far, so good. But RFC3264 goes on immediately afterwards and states that:

If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5], RFC3555 actually now) is to be used.

This allows easier migration away from static payload types.

Since a default payload type mapping for G.729 does exist (defined in RFC3555 as type 18 ), sipdiscount should accept this codec (but doesn't). Hence for the rejection of this codec...

Case closed, time to close some bug reports on the AVM helpdesk

Cheers for all the lads for the awesome tips, this fritz thingie can make coffee as well it seems. I just have to find the web admin page to do it

 

[hamlet]

SIPDiscount and FritzBoxFon

Hi,

I seem to have the same problem (Error 488), but I do not know so much about audio codecs.
How can I change the codec to a compatible one or is there any other solution?

Peter

 

[gandalf94305]

Use a different codec. By default, the FBF won't use G.729, unless you force it to use compressing codecs. Which settings do you use for VoIP quality?

However, 48x response codes normally don't occur with codec problems. There should be a different reason. 415 is "Unsupported Media Type", indicating a codec problem. Unfortunately, your error code is obscured by the smilie interpretation function of the forum... that's 488?

--gandalf.

 

[hamlet]

[Fullquote of gandalf94305 removed. Can't you read what's just one article up? @gandalf94305 is sufficient. --gandalf.]

Hi,

I was wrong with 488 (had that error code with sipgate). It was 415 actually.

I found the following information in the voip.cfg file:
---------------------------->8--------------------------------
use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";
verbose = no;
sip_prio = 0;
rtp_prio = 0;
dyn_codecs = yes;
rtpstream {
voice_activity_detection {
enabled = no;
vad_threshold = 10000;
}
generate_noise {
on_packetloss = no;
on_capi_underrun = yes;
}
jitter {
auto_on = yes;
in_ms = 50;
in_packets = 0;
}
tx_packetsize_in_ms = 0;
}
}
---------------------------->8--------------------------------
It seems that G.729 does not show up at all. Could you see anything other that can indicate the cause of the problem?


Peter

 

[maleas]

[Fullquote of hamlet removed. Can't you read what's just one article up? ANTWORTEN means REPLY, so please use this button instead of QUOTING. @hamlet is sufficient. --gandalf.]

Try modifying the relevant lines of /var/flash/voip.cfg to read as in the first post.

 

[gandalf94305]

First of all: PLEASE DON'T USE FULLQUOTES! Use quotes only where necessary and use @NAME to refer to NAME's last article. Thanks.

"use_audiocodecs = no" tells the FBF not to use the setting given by the line "audiocodecs = ...". Consequently, you use the FBF default settings. Try changing the quality to "Festnetzqualität" in the menu "Telefonie -> Internettelefonie -> Erweiterte Einstellungen" by choosing "immer Sprachkodierung mit Festnetzqualität verwenden".

Do you still encounter the 415 code?

--gandalf.

 

[hamlet]

Hi,

First of all I am very sorry for the fullqoute!
Unfortunately when I tried to modify the settings in voip.cfg my notebook lost connection to the FBF and my WLAN usb stick refused to work from this moment on. I hope I can connect to FBF via a simple crossed network cable to make the modification you suggested.
When it comes to editing voip.cfg do I have to create a new file an copy it over the original one as I got only an empty file when I typed in 'vi voip.cfg'?

Thank you very much for you hints
A voip newbee

 

[gandalf94305]

You don't use "vi voip.cfg" but rather "nvi voip.cfg". This file is in flash memory and needs some special treatment ;-)

--gandalf.

 

[hamlet]

Hello Gandalf,

For VOIP it seems to work. I have disabled the setting Telefonie -> Internettelefonie -> 'Bandbreitenoptimierte Sprachkompression verwenden'

Thanks for the hints
Peter