PAP2T: G726-32 codec defined incorrectly in SDP parameters

Unanswered Question
Jan 11th, 2010
User Badges:

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:[email protected] SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-516e3ae8
   From: 1000 <sip:[email protected]>;tag=93ac26a9afdf598o0
   To: <sip:[email protected]>
   Call-ID: [email protected]
   CSeq: 101 INVITE
   Max-Forwards: 70
   Contact: 1000 <sip:[email protected]: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.
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Alberto Montilla Mon, 01/11/2010 - 10:22
User Badges:
  • Cisco Employee,

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

Actions

This Discussion