[Home]

Summary:ASTERISK-15802: SIP response 415 "Unsupported Media Type" when using G729
Reporter:Jonas Kellens (jonaskellens)Labels:
Date Opened:2010-03-13 10:23:01.000-0600Date Closed:2011-07-27 13:38:35
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Codecs/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dialplan
( 1) verbose.asterisk.jocan.local
Description:Using Asterisk 1.4.25.1

Grandstream IP-phone has codecs G729, alaw, GSM.
Zoiper softphone has codecs alaw, GSM.

sip.conf peer definition grandstream :
disallow : all
allow : G729;alaw;GSM

sip.conf peer definition zoiper :
disallow : all
allow : alaw;GSM

When calling from zoiper softphone to Grandstream, the codec used is alaw.

When calling from Grandstream to Zoiper, the call fails with SIP response 415 "Unsupported Media Type".

Why is it that Asterisk does not negotiates about the alaw-codec between the Grandstream, Asterisk itself and the Zoiper softphone.

Is it normal behaviour that when one of the 2 SIP endpoints does not have a G.729 license and Asterisk does not hold the license to translate from G729 codec to another, the call fails ?

****** ADDITIONAL INFORMATION ******

<--- SIP read from 192.168.1.101:5061 --->
INVITE sip:20@192.168.1.150 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:5061;branch=z9hG4bK3f7d4c127d091c19
From: "TestCorp Jonas" <sip:testcorp3@192.168.1.150>;tag=8944a440ecb92462
To: <sip:20@192.168.1.150>
Contact: <sip:testcorp3@192.168.1.101:5061;transport=udp>
Supported: replaces, timer, path
Proxy-Authorization: Digest username="testcorp3", realm="domain.be", algorithm=MD5, uri="sip:20@192.168.1.150", nonce="48a892f9", response="b3c7444af48c962924e20fa528375d5a"
Call-ID: 6dcdf8ababffb4df@192.168.1.101
CSeq: 31566 INVITE
User-Agent: Grandstream GXP2010 1.2.1.4
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Content-Type: application/sdp
Content-Length: 268

v=0
o=testcorp3 8000 8001 IN IP4 192.168.1.101
s=SIP Call
c=IN IP4 192.168.1.101
t=0 0
m=audio 10100 RTP/AVP 18 3 8 101
a=sendrecv
a=rtpmap:18 G729/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11

<------------->
[Mar 13 17:17:32] --- (14 headers 13 lines) ---
[Mar 13 17:17:32] Sending to 192.168.1.101 : 5061 (NAT)
[Mar 13 17:17:32] Using INVITE request as basis request - 6dcdf8ababffb4df@192.168.1.101
[Mar 13 17:17:32] Found user 'testcorp3'
[Mar 13 17:17:32] Found RTP audio format 18
[Mar 13 17:17:32] Found RTP audio format 3
[Mar 13 17:17:32] Found RTP audio format 8
[Mar 13 17:17:32] Found RTP audio format 101
[Mar 13 17:17:32] Peer audio RTP is at port 192.168.1.101:10100
[Mar 13 17:17:32] Found audio description format G729 for ID 18
[Mar 13 17:17:32] Found audio description format GSM for ID 3
[Mar 13 17:17:32] Found audio description format PCMA for ID 8
[Mar 13 17:17:32] Found audio description format telephone-event for ID 101
[Mar 13 17:17:32] Capabilities: us - 0x10a (gsm|alaw|g729), peer - audio=0x10a (gsm|alaw|g729)/video=0x0 (nothing), combined - 0x10a (gsm|alaw|g729)
[Mar 13 17:17:32] Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[Mar 13 17:17:32] Peer audio RTP is at port 192.168.1.101:10100
[Mar 13 17:17:32] Looking for 20 in from-TESTCORP (domain 192.168.1.150)
[Mar 13 17:17:32] list_route: hop: <sip:testcorp3@192.168.1.101:5061;transport=udp>

[Mar 13 17:17:32] Audio is at 192.168.1.150 port 11540
[Mar 13 17:17:32] Adding codec 0x100 (g729) to SDP
[Mar 13 17:17:32] Adding non-codec 0x1 (telephone-event) to SDP
[Mar 13 17:17:32] Reliably Transmitting (NAT) to 192.168.1.107:5060:
INVITE sip:testcorp2@X.X.X.X:1045;rinstance=5b273356c765087a;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK6eaabbe5;rport
From: "TestCorp Jonas" <sip:testcorp3@192.168.1.150>;tag=as57ac27f0
To: <sip:testcorp2@X.X.X.X:1045;rinstance=5b273356c765087a;transport=UDP>
Contact: <sip:testcorp3@192.168.1.150>
Call-ID: 0ada62420319c4681e14c0494871e371@192.168.1.150
CSeq: 102 INVITE
User-Agent: domain
Max-Forwards: 70
Date: Sat, 13 Mar 2010 16:17:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 265

v=0
o=root 24971 24971 IN IP4 192.168.1.150
s=session
c=IN IP4 192.168.1.150
t=0 0
m=audio 11540 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
[Mar 13 17:17:32]     -- Called testcorp2
[Mar 13 17:17:32]
<--- SIP read from 192.168.1.107:5060 --->
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/UDP X.X.X.X:1045;branch=z9hG4bK6eaabbe5;rport=5060
To: <sip:testcorp2@X.X.X.X:1045;rinstance=5b273356c765087a;transport=UDP>;tag=2f50a251
From: "TestCorp Jonas"<sip:testcorp3@192.168.1.150>;tag=as57ac27f0
Call-ID: 0ada62420319c4681e14c0494871e371@192.168.1.150
CSeq: 102 INVITE
User-Agent: Zoiper rev.6387
Content-Length: 0


<------------->
[Mar 13 17:17:32] --- (8 headers 0 lines) ---
[Mar 13 17:17:32]     -- Got SIP response 415 "Unsupported Media Type" back from 192.168.1.107
[Mar 13 17:17:32] Transmitting (NAT) to 192.168.1.107:5060:
ACK sip:testcorp2@X.X.X.X:1045;rinstance=5b273356c765087a;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.150:5060;branch=z9hG4bK6eaabbe5;rport
From: "TestCorp Jonas" <sip:testcorp3@192.168.1.150>;tag=as57ac27f0
To: <sip:testcorp2@X.X.X.X:1045;rinstance=5b273356c765087a;transport=UDP>;tag=2f50a251
Contact: <sip:testcorp3@192.168.1.150>
Call-ID: 0ada62420319c4681e14c0494871e371@192.168.1.150
CSeq: 102 ACK
User-Agent: domain
Max-Forwards: 70
Content-Length: 0
Comments:By: Leif Madsen (lmadsen) 2010-03-15 11:12:01

I'm not sure if this is normal or not, so I'll mark this as Acknowledged until someone better equipped can respond.
By: Jonas Kellens (jonaskellens) 2010-03-15 11:36:06

When a G729-capable phone calls a non-capable phone through Asterisk then there is always the following that happens :

INVITE from g729-capable phone to Asterisk results in :

Capabilities: us - 0x10a (gsm|alaw|g729), peer - audio=0x10a (gsm|alaw|g729)/video=0x0 (nothing), combined - 0x10a (gsm|alaw|g729)

SDP in INVITE from Asterisk to non-capable phone :

Content-Type: application/sdp
Content-Length: 265

v=0
o=root 24971 24971 IN IP4 192.168.1.150
s=session
c=IN IP4 192.168.1.150
t=0 0
m=audio 11580 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

And the result is :

<--- SIP read from 192.168.1.107:5060 --->
SIP/2.0 415 Unsupported Media Type


So my point is : why does Asterisk only present g729 as codec ?? Why not present g729, alaw and gsm to the called peer ??

Then the peer can reply with codecs alaw & gsm in its SDP-body.

The moment I place the g729 as second codec in sip.conf, then the call uses alaw for both channels.
By: Leif Madsen (lmadsen) 2010-03-18 14:32:30

Can you provide your dialplan that is causing this issue?

Also, we need a FULL SIP debug of the issue from start to finish.
By: Jonas Kellens (jonaskellens) 2010-03-19 03:25:58

A full SIP debug is added as file upload.
The part of the dialplan that is important is added as file upload.
By: Karsten Schmidt (guggemand) 2010-03-31 12:46:03

Just want to say i have the same problem on 1.6.1.12

When a call comes in from a peer with disallow=all and allow=g729;alaw, the outgoing call to the destination only have g729 in the m=audio header.

I'll make some dumps later when i get home.
By: Jonas Kellens (jonaskellens) 2010-04-10 09:08:03

Is there yet some explanation/improvement on this issue ??
By: Paul Belanger (pabelanger) 2010-04-10 12:52:46

Can you also attach your sip.conf file?
By: Paul Belanger (pabelanger) 2010-04-10 13:35:00

I'll give this a shot, however I'm _not_ an expert by any means.

According to rfc3261.txt, 8.1.3.5 Processing 4xx Responses:
---
  If a 415 (Unsupported Media Type) response is received (Section
  21.4.13), the request contained media types not supported by the UAS.
  The UAC SHOULD retry sending the request, this time only using
  content with types listed in the Accept header field in the response,
  with encodings listed in the Accept-Encoding header field in the
  response, and with languages listed in the Accept-Language in the
  response.
---

However, looking at the trace I do not see the 'Accept' header field.  According to 8.2.3 Content Processing

---
  ... the UAS MUST reject the request with a 415
  (Unsupported Media Type) response.  The response MUST contain an
  Accept header field listing the types of all bodies it understands,
  in the event the request contained bodies of types not supported by
  the UAS.
---

That being said, I believe issue is a result of the Zoiper softphone. However, there _may_ be an issue here with asterisk, because we see:

  [Mar 19 09:19:28] VERBOSE[18601] logger.c: [Mar 19 09:19:28] Capabilities: us - 0x10a (gsm|alaw|g729), peer - audio=0x10a (gsm|alaw|g729)/video=0x0 (nothing), combined - 0x10a (gsm|alaw|g729)

however, only set G729 in the sdp:

  [Mar 19 09:19:28] VERBOSE[18634] logger.c: [Mar 19 09:19:28] Adding codec 0x100 (g729) to SDP

I would think, at a minimum we should be also setting alaw, and gsm. But like lmadsen said 'ntil someone better equipped can respond'. :)
By: David Vossel (dvossel) 2010-08-30 12:36:47

Are you using the 'directmedia' or 'canreinvite' option in sip.conf?
By: Jonas Kellens (jonaskellens) 2010-08-30 13:49:52

Using realtime SIP peers and all of my SIP peers have :

canreinvite=no

(so Asterisk stays in the media path)

I am not using directmedia (if it has a default value, then maybe the default value is used)
By: Russell Bryant (russell) 2011-07-27 13:38:29.199-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!