[RESOLVED] Getting a SIP response 488 "Not Acceptable M

Asterisk Asterisk Support
1

Hi guys,
suddenly I am getting the Got SIP response 488 “Not Acceptable Media” message back when a call comes in from a PRI to the Asterisk box routed to a Cisco 5300.
The strange thing is this only happens with some calls.
I did not change anything on how I treat calls on the Cisco nor any changes where done on the Asterisk configuration either.

Asteisk is version 1.2.7.1
PRI is a Euro-ISDN configured PRI that otherwise works excellent both ways.

This *apparently" started when the PSTN (Telmex in Brasil) changed (even though they swear not having changed anything) how I was receiving the ANI.
Up until 2 days ago, I was receiving the ANI as as a local number in 11xxxxxxxx format. Yesterday suddenly we were receiving them as 011xxxxxxxx
Form what I have been able to research the above error could be something callerID related, but wouldn’t that affect all calls?

Any clues what might be happening here?
Any help is appreciated :smile:

Cheers

2

The NOT ACCEPTABLE MEDIA response is usually do to a call coming in using a codec that asterisk does not support. For example if the call came in using G.729 and you did not have G.729 support on the asterisk server, asterisk would generate this response.

To see the source of the problem, you need to look at the SDP on a incoming call where asterisk is producing this response.

3

The issue is the call is coming IN on the E1… same as all other calls, but just some have this issue.
The call flow is:

PSTN -> E1 (PRI) -> Asterisk -> Internet (SIP) -> Cisco 5300 -> T1 (PRI) - > Switch

Here’s the first part of a SIP Debug on the Cisco side:

1d06h: Received:
INVITE sip:55112200@198.67.xx.xx SIP/2.0
Via: SIP/2.0/UDP 200.186.xxx.xx:5060;branch=z9hG4bK667c5bca;rport
From: “0115505xxxx” sip:0115505xxxx@200.186.xxx.xx;tag=as44005445
To: sip:55112200@198.67.xx.xx
Contact: sip:0115505xxxx@200.186.xxx.xx
Call-ID: 117ec3634fdbd3e0343f5b8e5acb382b@200.186.xxx.xx
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Thu, 26 Oct 2006 20:05:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 219

v=0
o=root 11920 11920 IN IP4 200.186.xxx.xx
s=session
c=IN IP4 200.186.xxx.xx
t=0 0
m=audio 14928 RTP/AVP 3 101
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

1d06h: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 200.186.xxx.xx:5060
1d06h: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg
1d06h: 0x62B74CB8 : State change from (STATE_NONE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE)
1d06h: CCSIP-SPI-CONTROL: act_idle_new_message
1d06h: sip_stats_method
1d06h: CCSIP-SPI-CONTROL: sact_idle_new_message_invite
1d06h: CCSIP-SPI-CONTROL: sipSPIUASSessionTimer
1d06h: ****Adding to UAS Request table. ccb=0x62B74CB8 key=117ec3634fdbd3e0343f5b8e5acb382b@200.186.xxx.xx55112200
1d06h: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup
1d06h: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup: Match not found on carrier id
1d06h: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup: Match not found on Incoming called number: 55112200
1d06h: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup: Match not found on destination pattern: 0115505xxxx
1d06h: CCSIP-SPI-CONTROL: sipSPIContinueNewMsgInvite
1d06h: sipSPIGetGtdBody: No valid GTD body found.
1d06h: UpdateSIPQ931Params: Calling Oct3: 0x00
1d06h: UpdateSIPQ931Params: Calling Oct3a: 0x80
1d06h: UpdateSIPQ931Params: Called Oct3: 0x80
1d06h: Received ;screen= ;privacy= -> Setting Octet3A=0x80
1d06h: sipSPIContinueNewMsgInvite:Not Using Voice Class Codec

1d06h: sipSPICopyPeerDataToCCB: From CLI: Modem NSE payload = 100, Passthrough = 0,Modem relay = 0, Gw-Xid = 1
SPRT latency 200, SPRT Retries = 12, Dict Size = 1024
String Len = 32, Compress dir = 3
1d06h: sipSPIHandleInviteMedia
1d06h: sipSPIDoMediaNegotiation: number of m lines is 1
1d06h: Dynamic Payload :101 in SDP Body

1d06h: sipSPIDoAudioNegotiation: No matching voice codec found for m-line 1
1d06h: sipSPIDoDTMFRelayNegotiation: m-line index 1
1d06h: sipSPIDoDTMFRelayNegotiation: Requested DTMF-RELAY option(s) not found in Preferred DTMF-RELAY option list!
1d06h: sipSPIStreamTypeAndDtmfRelay: ERROR - no voice codec and no dtmf-relay match
1d06h: sipSPIStreamTypeAndDtmfRelay: DTMF Relay mode : Inband Voice

1d06h: sipSPIGetSDPDirectionAttribute: No direction attribute present or multiple direction attributes that can’t be handled for m-line:1 and num-a-lines:0

1d06h: sipSPIDoAudioNegotiation: Media negotiation failed for m-line 1

1d06h: sipSPIDoMediaNegotiation: ERROR - no valid fax or audio streams
1d06h: sipSPIHandleInviteMedia: Media Negotiation failed for an incoming call - Sending 488

1d06h: CCSIP-SPI-CONTROL: sipRequestError
1d06h: CCSIP-SPI-CONTROL: sipSPISendInviteResponse
1d06h: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE

4

anyone? :open_mouth:

5

Your SDP going to the cisco shows it is requesting GSM as the codec. The log from the cisco is saying “no matching voice codec found for m-line 1” so it looks like the cisco does not support GSM. Yiou will need to change the allowed codecs setting in your sip.conf to disallow GSM, and then you will want to allow whatever codec will work with the cisco, most likely ulaw or alaw.

6

Thanks for your reply SuperB.
But, the issue is, this only happens with some calls. ALL others are processed fine, with GSM codec… I know it sounds weird, but thats what is happening and has me posting this here…
it always happens with the same originating numbers… so it must be something coming form the PRI causing this… the question is, how do I override/fix this…

7

Mrbyte,

Unless your diagram is missing a device, it looks like the E-1 is coming directly into the asterisk server. The E-1 circuit does not specify a codec to use. To fix the problem you need to add the following lines to sip.conf where you have it configured to communicate with the cisco box:

disallow=all
allow=ulaw

That should make it work in all cases.

8

[quote=“SuperB”]Mrbyte,

Unless your diagram is missing a device, it looks like the E-1 is coming directly into the asterisk server. The E-1 circuit does not specify a codec to use. To fix the problem you need to add the following lines to sip.conf where you have it configured to communicate with the cisco box:

disallow=all
allow=ulaw

That should make it work in all cases.[/quote]

I think I tried, but was getting then other errors. Will try again though, but that would kind of defeat the purpose of having a remote Asterisk box if I need to go ulaw…

Here’s the call flow:

PSTN (E1/PRI) -> Asterisk -> Internet (SIP) -> Cisco -> Switch (T1/PRI)

As of now, we have found a pattern of all calls that fail coming from a specific NPA in Sao Paulo.
What I still don’t understand, is why some calls create this issue and others don’t. I know ISDN/PRI has no “codec” request setting, so why are these calls failing with GSM?
There must be something else we’re mising here. ican take a SIP trace as well form the Asterisk side, but it is not much different than the one I alsready posted from the Cisco side… SIP messages are SIP messages.

Any other ideas?

9

Post the SDP of a good call and let’s take a look at the codecs in the m-line and see what is different.

Asterisk is the device setting up the SIP call, so it is in control of what codecs, based on your sip.conf are used when communicating with the Cisco device.

10

SuperB,
thanks again for your reply.
I was able to solve the issue.
One more reason pointin towards that Telmex DID change something altough they insist they did not.
Here is the reason they where failing:

  • calls where coming into the Cisco before, with the local ANI in Sao Paulo, which was 11xxxx.

  • Calls where now coming in as 011xxxx

  • all problem calls where from a certain exchange, in this case 01155xxx

  • we had a voip dialpeer on the Cisco that has a pattern of 01155T

    As calls came in, and the cisco was matching the dialpeers, it came into the Cisco on the propper one, but as the ANI did also match this other diapleer, it apparently was trying to reroute the call, which obviously failed.

    I did manipulate now the ANI on the Asterisk box to strip the 0 and prefix it with something, so it did not match any other pattern on the Cisco…and now it all works beatifully.

    Now I need to check again, why the ANI was being matched with an outbound Dialpeer… but all is working now.

Thanks again for your help :smile: