Call is disconnected with SIP error 488
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-15-2020 06:20 AM
Hello the Community
I am currently experiencing a call disconnection problem between Jabber.
Call flow:
Caller Jabber --> CUCM --> UCCX --> CTI Port --> My Agent Jabber
When I check the SIP tarces, I found that we receive an SIP Message 488 Not Acceptable Media.
I think that it's a codec issue or something like that.
How can I confirm the root cause and How can I solve it?
Thanks for your help
Regards
Sébastien
- Labels:
-
Jabber
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-17-2020 11:55 PM
You need to share the logs to determine the cause for failure. BTW, it might looks codec issue. If that is the case, You can try to use a transcoder and apply to SIP trunk device pool or make sure the audio codec preference list which you have set on dial-peers have all codecs listed such as G729br8,G729 etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2020 01:51 AM
Hi Nagaraj,
The problem is that in my case we have not SIP trunk.
I noted that the problem occurs when the CSF is under recording. When CSF is not recorded, we have no problem.
I will clear my log and I will share it with you.
Thanks
regards
Sébastien
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2020 05:38 AM
Can check the codec preference in the gateway
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 isac mode independent bit-rate 32000 framesize 30
codec preference 3 g729r8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-23-2020 12:42 AM
Hi Balaji,
Thanks for your reply.
But in my case, we don't go through the gateway.
It's for the internal call between Jabber for VDI and Contact Center Agent
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2020 05:39 AM
Can share the sip traces this dicussion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2020 05:44 AM
From SIP message are receive this message
Sent:
SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/UDP IP:5060;branch=z9hG4bK-b8555e-d00d7801-18f2e55
From: <sip:4033131776@ip>;tag=8e28930-0-13c4-55013-b8555b-71de78c1-b8555b
To: <sip:+12024655568@lii01.livun.com>;tag=56E55DB8-AC
Date: Tue, 17 Oct 2017 21:30:16 GMT
Call-ID: 31E69A60-B2B911E7-B7F6EA97-D6A08AF@lii01.livun.com
CSeq: 1 INVITE
Allow-Events: kpml, telephone-event
Server: Cisco-SIPGateway/IOS-15.5.3.S2
Content-Length: 0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2020 09:35 AM
You would need to share a little bit more of the output of the debug than this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 06:02 AM
This sample 488 error message log next page
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Recv-Info: x-broadworks-client-session-info
Accept: application/btbc-session-info,application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 19
Content-Type: application/sdp
Content-Length: 167
v=0
o=- 3305155623 1 IN IP4 172.30.1.4
s=-
c=IN IP4 172.30.1.4
t=0 0
m=audio 50194 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
076454: *Oct 17 2017 21:30:13.381: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Calling Number=4033131776, Called Number=4033131776, Peer Info Type=DIALPEER_INFO_SPEECH
076455: *Oct 17 2017 21:30:13.381: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=4033131776
076456: *Oct 17 2017 21:30:13.381: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 08:49 AM
m=audio 50194 RTP/AVP 0 101
This line states what codec and DTMF method that is supported. It only list one codec, 0=g711ulaw, 101 is the payload type for DTMF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 06:07 AM
488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable), but only
applies to the specific resource addressed by the Request-URI and the
request may succeed elsewhere.A message body containing a description of media capabilities MAY be
present in the response, which is formatted according to the Accept
header field in the INVITE (or application/sdp if not present), the
same as a message body in a 200 (OK) response to an OPTIONS request.
Often 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.
For fix that you should check both side configuration, I mean if you got an error for a SIP trunk you should check the SIP trunk provider codec and config if it’s interconnection in your company you should check the second server configuration.
For finding and debugging the codec for both side, you can capture SIP session by tools like Wireshark; you can check the codec for each call.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 06:07 AM
problem is still unresolved, there is one more step.
Most of SIP provider want Early Offer INVITEs. They use this always to decide on which codec to offer for the calls.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-23-2020 12:52 AM
Hello the community,
I added the SDL trace from my CUCM sub for the impacted call.
Timestamp for the impacted call:
call starts: 10h28:32
End call:10h28:35
CallId: 0205857f-eb800007-000076d0-00002876
Thanks
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-23-2020 11:46 PM
Hello,
After some tests, I noted that the service parameter G.722 codec enabled is not apply to Jabber Softphone.
In my case this parameter is disabled and when I do a test with one CSF, I can see that the invite contains G.722 and G.722.1 in SDP.
is it normal?
How can I remove this codec during the Invite?
Thanks
regards
Sébastien
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-24-2020 03:46 AM
