PAP2T: G726-32 codec defined incorrectly in SDP parameters

mcampbellsmith · ‎01-11-2010

Hi!

I was trying to use G726-32 codec, but I had some issues with one of my voip providers, together with FreeSWITCH. The problem appears to be the way the G726-32 codec is defined in the SDP parameters:

   INVITE sip:2010@192.168.1.120 SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-516e3ae8
   From: 1000 <sip:1000@192.168.1.120>;tag=93ac26a9afdf598o0
   To: <sip:2010@192.168.1.120>
   Call-ID: 4845f852-c965f8d0@192.168.1.121
   CSeq: 101 INVITE
   Max-Forwards: 70
   Contact: 1000 <sip:1000@192.168.1.121:5060>
   Expires: 240
   User-Agent: Linksys/PAP2T-5.1.6(LS)
   Content-Length: 368
   Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
   Supported: x-sipura, replaces
   Content-Type: application/sdp

   v=0
   o=- 20427387 20427387 IN IP4 192.168.1.121
   s=-
   c=IN IP4 192.168.1.121
   t=0 0
   m=audio 16454 RTP/AVP 2 0 8 96 97 100 101
   a=rtpmap:2 G726-32/8000

According to RFC3551, payload type 2 above (in the m=audio and the a=rtpmap:2) is reserved.

Quote: '

Entries in Tables 4 and 5 with payload
   type "dyn" have no static payload type assigned and are only used
   with a dynamic payload type.  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

Thus the PAP2T should not use payload type 2 at all.  I believe this is a fault in the firmware.

Alberto Montilla · ‎01-11-2010

Dear Sir;

Please go to the [SIP] tab and change the codec number for G726-32 in the following parameter: G726r32 Dynamic Payload. That should make the deal.

Regards,
Alberto

mcampbellsmith · ‎01-12-2010

Thanks.. that fixed it!