Call is disconnected with SIP error 488

[Sebastien Denoncin]

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

[nagaraj789]

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.

[Sebastien Denoncin]

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

[BalajiSivaraj49175]

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

[Sebastien Denoncin]

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

[BalajiSivaraj49175]

Can share the sip traces this dicussion

[BalajiSivaraj49175]

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

[Roger Kallberg]

You would need to share a little bit more of the output of the debug than this.

[BalajiSivaraj49175]

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

[Roger Kallberg]

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.

[BalajiSivaraj49175]

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.

[BalajiSivaraj49175]

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.

[Sebastien Denoncin]

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

[Sebastien Denoncin]

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

[BalajiSivaraj49175]

Codec preference can preferred from following link

https://www.google.com/search?q=how+to+change+the+codes+preferance+in+CUCM&oq=how+to+change+the+codes+preferance+in+CUCM&aqs=chrome..69i57.14118j1j15&sourceid=chrome&ie=UTF-8#kpvalbx=_GH_kX7uhM_3Az7sPnJ-mcA13