SPA interop issue and G.729 Annex 'a' RFC problem

[sn0wm0nster]

Hello.

I am not very familiar with the Cisco SPA IP phone but i am researching an issue for my customer who is using SPA 303, 504G, 509G, 525G

My 1st and main question is how can i configure my customers SPA IP phones to advertise "G.729" in the SIP SDP and *not* G.729a?

This will solve many interoperability issues with other vendor's SIP implementations.

My second question is related to my first one.

Why do the Cisco SPA IP phones advertise "G.729a" in the SDP as payload type 18 and using a MIME type of "G.729a" when this not RFC compliant?

I understand that G.729 and G.729a are bitstream compatible but advertising as "G.729a" in the SDP is wrong according to RFC documents and causes many interoperability issues.  Even if the device is using G.729a to encode it's audio stream it should still advertise this as only "G.729" in the SDP.  The Cisco SPA is not compliant with the RFC specs by advertising as "G.729a" in the SIP SDP.

For your reference.

According to RFC3555 (section 4.1.9) "G.729" is listed as a registered MIME type..."G.729a" is *not*

According to RFC3551, (section 4.5.6) Indicates that implementations should signal or accept G.729 but can implement either G.729 or G.729a.  Because the speech coding algorithms in the main body of G.729 and in G.729 Annex 'A' are fully interoperable with each other, explicitly advertising G.729a is not required.

According to the IANA list of registered RTP payload types, G.729 should be advertised as Payload type 18. 

There is *no* payload type for "G.729a" as it is not required to be explicitly advertised, yet the cisco SPA is explicitly advertising "G.729a" as Payload type 18!!??

Only "G.729" should be advertised as payload type of 18...not "G.729a".

If you could help with my first question that would be really great as it would at least solve my customers issues.

If your able to help explain or raise a change request around my second question that would be even better.

Thank you in advance for your help, it's much appreciated.

Sn0m0nster

[sn0wm0nster]

I managed to answer my own first question. 

For anyone else who comes across this issue you can renamed the 'codec name' setting from "G.729a" to "G.729" via the phones (504g for example) advanced section on the UI or you can modify the config file that is provisioned out to all your phones.  This solves the interop issue and means the phone is now correctly advertising the codec.

As for question 2, Anyone from Cisco want to comment on why the SPA IP phones advertise G.729 incorrectly according to the RFC's?

From what i see from searching other forums It seems they have done this incorrectly since way back when they were Sipura IP phones.

[sn0wm0nster]

A shame no one from Cisco would like to comment on this.  oh well.

[Alberto Montilla]

Hi Sn0wm0nster;

It is about backward compatibility. Old RFC definition had G.729a. Your resolution is right, just change the name.

Actually name should not matter but the number attached to the name, this is another issue of RFC interpretation. Servers looking at number only had zero confussion on major codecs, but a few adds the name to the check.

Regards
Alberto