Unexpected 488 Not Acceptable Here

Asterisk Asterisk SIP
1

Hi, I have a re-invite problem with certain connections.

I think I know why I am getting the 488 (Not Acceptable Here) response, but I’d appreciate if someone could confirm my findings.

I think it is not an Asterisk problem and there is no way to deal with that at the PBX level. In many cases the 488 response has to do with media related problems. Here it is not like that.

It starts with the initial INVITE for the incoming call

INVITE sip:+49242569696@80.180.170.160:5060;transport=TCP;line=ltyavtl SIP/2.0
Via: SIP/2.0/TCP 217.0.17.117:5060;branch=z9hG4bKc46d33febaebfa13e36a15e6f4584072.bf5dc1cc
Record-Route: sip:reg.sip-trunk.telekom.de;transport=tcp;lr
Max-Forwards: 60
To: sip:+49242569696@telekom.de;user=phone
From: sip:+491632123456@sip-trunk.telekom.de;user=phone;tag=f7f18b7f
Call-ID: ac8da322f071a561@87.137.137.37
Contact: sip:C/lXxOcUJWUSRAASY1XNUgiQnC8SNzj+smH/gtWr/KZdAbbngHS2HhA7dR+l0XLktsKd@th1
Supported: 100rel,histinfo,timer
Session-Expires: 1800;refresher=uac
CSeq: 40538774 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, UPDATE
Expires: 180
Min-SE: 900
P-Asserted-Identity: sip:+491632123456@sip-trunk.telekom.de;user=phone
P-Called-Party-ID: sip:+49242569696@sip-trunk.telekom.de;user=phone
Session-ID: 76dd79af37d124065aaf757864ccd18c;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 933

v=0
o=- 59679659490453 59679659490453 IN IP4 217.0.17.117
s=on transit
c=IN IP4 217.0.133.133
t=0 0
a=sendrecv
m=audio 9798 RTP/AVP 109 104 9 102 8 0 110 108 105 100
b=RR:1875
b=RS:625
b=AS:80
a=sendrecv
a=rtpmap:109 EVS/16000
a=rtpmap:104 AMR-WB/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 AMR/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:110 AMR-WB/16000
a=rtpmap:108 AMR/8000
a=rtpmap:105 telephone-event/16000
a=rtpmap:100 telephone-event/8000
a=maxptime:240
a=msi:mavodi-0-15b-3ef-10-ffffffff-5a250000-5d8a6e6fcc73d-1219-ffffffffffffffff-@10.137.255.3-10.137.195.3&&UAGESS04-65
a=fmtp:109 br=5.9-24.4;bw=nb-swb;cmr=1;max-red=0
a=fmtp:104 mode-change-capability=2;max-red=220
a=fmtp:102 mode-change-capability=2;max-red=220
a=fmtp:110 octet-align=1;mode-change-capability=2;max-red=220
a=fmtp:108 octet-align=1;mode-change-capability=2;max-red=220
a=fmtp:105 0-15
a=fmtp:100 0-15
a=ptime:20

followed by the usual 100 and 180 responses (from my side). Eventually there is a standard 200 response:

SIP/2.0 200 OK
Via: SIP/2.0/TCP 217.0.17.117:5060;rport=5060;received=217.0.17.117;branch=z9hG4bKc46d33febaebfa13e36a15e6f4584072.bf5dc1cc
Record-Route: sip:217.0.17.117:5060;transport=TCP;lr
Call-ID: ac8da322f071a561@87.137.137.37
From: sip:+491632123456@sip-trunk.telekom.de;user=phone;tag=f7f18b7f
To: sip:+49242569696@telekom.de;user=phone;tag=513d6938-8b43-4674-81a6-86e469a22c3b
CSeq: 40538774 INVITE
Server: Asterisk PBX 19.3.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: sip:80.180.170.160:5060;transport=TCP
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 289

v=0
o=- 1088912533 1088912535 IN IP4 80.180.170.160
s=Asterisk
c=IN IP4 80.180.170.160
t=0 0
m=audio 18524 RTP/AVP 8 0 9 100
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

which gets acknowledged with

ACK sip:80.180.170.160:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 217.0.17.117;branch=z9hG4bK0ca28a30cc389f34ccdcb10b0325fd32.e27d508d
Record-Route: sip:reg.sip-trunk.telekom.de;transport=tcp;lr
Max-Forwards: 61
To: sip:+49242569696@telekom.de;user=phone;tag=513d6938-8b43-4674-81a6-86e469a22c3b
From: sip:+491632123456@sip-trunk.telekom.de;user=phone;tag=f7f18b7f
Call-ID: ac8da322f071a561@87.137.137.37
Contact: sip:C/lXxOcUJWUSRAASY1XNUgiQnC8SNzj+smH/gtWr/KZdAbbngHS2HhA7dR+l0XLktsKd@th1
CSeq: 40538774 ACK
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, UPDATE
Content-Length: 0

Nothing special here and the media flows in both directions. After about 7 minutes the caller re-invites with the following headers:

INVITE sip:80.180.170.160:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 217.0.17.117:5060;branch=z9hG4bK7096d10fc94abd8f2c7d968a6a59b92f.8904ce93
Record-Route: sip:reg.sip-trunk.telekom.de;transport=tcp;lr
Max-Forwards: 61
To: sip:+49242569696@telekom.de;user=phone;tag=513d6938-8b43-4674-81a6-86e469a22c3b
From: sip:+491632123456@sip-trunk.telekom.de;user=phone;tag=f7f18b7f
Call-ID: ac8da322f071a561@87.137.137.37
Contact: sip:C/lXxOcUJWUSRAASY1XNUgiQnC8SNzj+smH/gtWr/KZdAbbngHS2HhA7dR+l0XLktsKd@th1
Supported: timer
Session-Expires: 1800;refresher=uac
CSeq: 40538775 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PUBLISH, REFER, REGISTER, SUBSCRIBE, UPDATE
Expires: 180
Min-SE: 900
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 900

v=0
o=- 59679659490453 59679659490454 IN IP4 217.0.17.117
s=on transit
c=IN IP4 0.0.0.0
t=0 0
a=sendrecv
m=audio 0 RTP/AVP 109 104 9 102 8 0 110 108 105 100
b=RR:1875
b=RS:625
b=AS:80
a=rtpmap:109 EVS/16000
a=rtpmap:104 AMR-WB/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 AMR/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:110 AMR-WB/16000
a=rtpmap:108 AMR/8000
a=rtpmap:105 telephone-event/16000
a=rtpmap:100 telephone-event/8000
a=maxptime:240
a=msi:mavodi-0-15b-3ef-10-ffffffff-5a250000-5d8a6e6fcc73d-1219-ffffffffffffffff-@10.137.255.3-10.137.195.3&&UAGESS04-65
a=fmtp:109 br=5.9-24.4;bw=nb-swb;cmr=1;max-red=0
a=fmtp:104 mode-change-capability=2;max-red=220
a=fmtp:102 mode-change-capability=2;max-red=220
a=fmtp:110 octet-align=1;mode-change-capability=2;max-red=220
a=fmtp:108 octet-align=1;mode-change-capability=2;max-red=220
a=fmtp:105 0-15
a=fmtp:100 0-15

which gets the 488 response

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/TCP 217.0.17.117:5060;rport=5060;received=217.0.17.117;branch=z9hG4bK7096d10fc94abd8f2c7d968a6a59b92f.8904ce93
Record-Route: sip:217.0.17.117:5060;transport=TCP;lr
Call-ID: ac8da322f071a561@87.137.137.37
From: sip:+491632123456@sip-trunk.telekom.de;user=phone;tag=f7f18b7f
To: sip:+49242569696@telekom.de;user=phone;tag=513d6938-8b43-4674-81a6-86e469a22c3b
CSeq: 40538775 INVITE
Accept: application/dialog-info+xml, application/simple-message-summary, application/pidf+xml, application/xpidf+xml, application/cpim-pidf+xml, application/pidf+xml, application/dialog-info+xml, application/simple-message-summary, application/sdp, message/sipfrag;version=2.0
Server: Asterisk PBX 19.3.0
Content-Length: 0

The rest is an ACK, followed by BYE and the terminating 200.

The second INVITE does not have the line parameter, which was initially honored, and the session description does not have a valid IP in the connection line c=. Both parameters are set by the calling party or one of the proxies in the flow of the call, i.e. Asterisk can’t do anything about that. The result is that the call immediately terminates.

Has someone seen this kind of behavior before?

The calling party was a mobile device in a car and the re-invite was issued when the German Belgium border was crossed. It looks as if something wanted to negotiate new media, when the old stream became unavailable. Obviously, it failed. Does anyone see a misconception in the analysis here?

2

a=sendrecv is allowed outside a media stream definition, but it is simply used a the default, and still contradicts the 0.0.0.0 in the c line.

3

I’ve now checked the rtcp data. The mos values were pretty low and there was already packet loss before the call dropped.

4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.