"SIP/2.0 488 Not acceptable here" error

kamran ghiasvand picture kamran ghiasvand · Apr 6, 2013 · Viewed 55.4k times · Source

I am new to MjSip and I use MjUa for creating a client. I want to connect to a asterisk server. it support G.711 but I can not config my app. I use this config:

 media=audio 4000 rtp/avp {audio 0 PCMU 8000 160, audio 8 PCMA 8000 160}

but i still get 488 error please help me. how change "MjUa" config file?


here is all message log:

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK2bfdff77
Max-Forwards: 70
To: "Alice" <sip:[email protected]:5060>
From: "aziz" <sip:[email protected]>;tag=350164683297
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Expires: 3600
User-Agent: mjsip 1.7
Content-Length: 141
Content-Type: application/sdp

v=0
o=157 0 0 IN IP4 192.168.0.57
s=-
c=IN IP4 192.168.0.57
t=0 0
m=audio 4000 rtp/avp 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
-----End-of-message-----

1365314026097: 10:23:46.097 Sun 07 Apr 2013, 192.168.0.254:5060/udp (519 bytes) received
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.57:5060;branch=z9hG4bK2bfdff77;received=192.168.0.57;rport=5060
From: "aziz" <sip:[email protected]>;tag=350164683297
To: "Alice" <sip:[email protected]:5060>;tag=as3f160681
Call-ID: [email protected]
CSeq: 1 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="6e640e9a"
Content-Length: 0

-----End-of-message-----

1365314026107: 10:23:46.107 Sun 07 Apr 2013, 192.168.0.254:5060/udp (326 bytes) sent
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK2bfdff77
Max-Forwards: 70
To: "Alice" <sip:[email protected]:5060>;tag=as3f160681
From: "aziz" <sip:[email protected]>;tag=350164683297
Call-ID: [email protected]
CSeq: 1 ACK
User-Agent: mjsip 1.7
Content-Length: 0

-----End-of-message-----

1365314026151: 10:23:46.151 Sun 07 Apr 2013, 192.168.0.254:5060/udp (706 bytes) sent
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK644461b7
Max-Forwards: 70
To: "Alice" <sip:[email protected]:5060>
From: "aziz" <sip:[email protected]>;tag=350164683297
Call-ID: [email protected]
CSeq: 2 INVITE
Contact: <sip:[email protected]>
Expires: 3600
User-Agent: mjsip 1.7
Authorization: Digest username="157", realm="asterisk", nonce="6e640e9a", uri="sip:[email protected]:5060", algorithm=MD5, response="84ff5e12b8325a153e09ac2e316f5b1f"
Content-Length: 141
Content-Type: application/sdp

v=0
o=157 0 0 IN IP4 192.168.0.57
s=-
c=IN IP4 192.168.0.57
t=0 0
m=audio 4000 rtp/avp 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
-----End-of-message-----

1365314026152: 10:23:46.152 Sun 07 Apr 2013, 192.168.0.254:5060/udp (450 bytes) received
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 192.168.0.57:5060;branch=z9hG4bK644461b7;received=192.168.0.57;rport=5060
From: "aziz" <sip:[email protected]>;tag=350164683297
To: "Alice" <sip:[email protected]:5060>;tag=as3f160681
Call-ID: [email protected]
CSeq: 2 INVITE
Server: FPBX-2.8.1(1.8.11.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

-----End-of-message-----

1365314026155: 10:23:46.155 Sun 07 Apr 2013, 192.168.0.254:5060/udp (326 bytes) sent
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.57:5060;rport;branch=z9hG4bK644461b7
Max-Forwards: 70
To: "Alice" <sip:[email protected]:5060>;tag=as3f160681
From: "aziz" <sip:[email protected]>;tag=350164683297
Call-ID: [email protected]
CSeq: 2 ACK
User-Agent: mjsip 1.7
Content-Length: 0

-----End-of-message-----

Answer

namezero picture namezero · Mar 28, 2014

A little late, but often times this is related to codec incompatibilities. For anyone encountering this issue, they should check whether both sides (server and client) have at least one codes they can negotiate.

From the log posted:

a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

It appears that G711 is requested but unavailable on the server side. Hence the server rejects the RTP channel.