Inbound SIP call disconnects when picked up

[TaylorAlexis04298]

Im having an issue with inbound sip calls, the dialpeer is matched and the call is sent to a hunt queue however when the call is picked up from the phone it immediately disconnects.

Its just a simple CME setup with no CUCM.

According to the provider the codecs used are G.711a /G.711u and G.729.

Which should be covered by

voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729br8
codec preference 4 g729r8
!

Which is applied to the incoming dial peer using

voice-class codec 1

ive also tried 

voice-class codec 1 offer-all

Ive attached the config and syslog for debug ccsip messages and errors

Can anyone suggest what is causing this ?

[Roger Kallberg]

Looks like you are sending the call off to some external system for the hunt part. That dial peer does not have any codec list assigned to it and I would also want to know a bit more about the details on the system you sent it off to.

* Update *
Sorry I redact what I wrote earlier. Looks like I need more coffee this morning.

[TaylorAlexis04298]

It does seem like a codec issue the logs show Disconnect Cause=47 the codec is listed as a=rtpmap:18 G729/8000 in the initial invite.

In debug ccsip error im getting the following

//-1/xxxxxxxxxxxx/SIP/Error/voipCodec_to_rtpAvpCodec:
10.0.1.10 Nov 20 12:26:03 local7 debug 220828 Unexpected VoIPCodec Type :No Codec

Even though all this should be covered by 

voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729r8
codec preference 4 g729br8
!

dial-peer voice 1005 voip
description Incoming 
translation-profile incoming Hunt
session protocol sipv2
session target sip-server
incoming called-number 12039028475
voice-class codec 1 
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
dtmf-relay sip-notify rtp-nte
no vad

Ive attached debug ccsip error and debug voip ccapi inout

Really scratching my head on this one, Its just a single interface router connected to a sip provider.

[Roger Kallberg]

If I’m not remembering all wrong I think you can setup a voice-class codec list to be used for your CME SIP configuration. Try that out to see if it makes any difference. Also make sure that your dead sure about what dial peer that is used for the inbound call leg from the ITSP. Based upon your configuration it looks like you might have tried a few different options for this. I’m a fan of having a clear inbound and outbound dial peer split, as that in my view gives you a much clearer sense of direction for calls when you look in either debugs or show commands. What is of upmost importance it to make sure you don’t use the dreaded built in dial peer 0 as this would always be using g729.

[TaylorAlexis04298]

To try and solve this ive reduced the config down as much as possible removed all my bvi's and vlans etc there is only 1 ethernet and 1 dial peer which is the incoming one. I can see in the logs its being matched and the phone rings so its getting that far.  

Should i even need a transcoder ? All im trying to do is have inbound calls work ? i can see from the logs they are meant to use g729 in the initial invite but all inbound calls drop with code 47 as soon as they are answered.

[Roger Kallberg]

With correct configuration you should not need to have a transcoder. You wrote that you have 1 Ethernet connection.

Normally you would have 2 interfaces with an SBC. One connected to the ITSP and the other connected to your internal network, this is also where the phones are connected. With this setup you get a clear demarcation point between your internal network and the external service provider for ITSP services. Both signaling and RTP stream from/to the phones will flow through the SBC to/from the ITSP service provider.

Can you do a debug ccsip messages and post the result as a file so that we can check what happens?

[TaylorAlexis04298]

Sure. Here are the debug files when an incoming call is taking place and picked up.

Ive included ccapi inout and ccsip error also if it helps.

[Roger Kallberg]

I would recommend you to redo the design for your SBC to have two interfaces as I described before and to properly configure it as an SBC. You are also missing a command to turn on the Cube functionality, “address-hiding” under voice service voip.
Once you have the setup in place you should be able to test again, this time with the media and signaling being handled by you SBC and not as today direct between the endpoint and the ITSP. That's a bad design as that reveals your inside network to your service provider.

[TaylorAlexis04298]

In addition i have configured a transcoder to try and resolve this

dspfarm profile 1 transcode universal
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
codec g729br8
codec g729r8
maximum sessions 26
associate application CUBE
!

voice-card 0
dsp services dspfarm

no shutdown
!

However even with this registered the call is still dropping with code 47

[Mohammed al Baqari]

Hi,

1. Do you have one of the call legs using G711? If yes, don't use a
universal transcoder. Use a general one.
2. Where is the transcoder registered? If the codes are different between
CUBE dialpeers, it should be registered to cube itself.

***** please remember to rate useful posts

[Roger Kallberg]

What would be the reason for your recommendation to not to use a universal transcoder if one of the call legs are g711?

[Mohammed al Baqari]

Hi,

Because the gateway will reserve more DSP resources if universal xcoder is
used to ensure that non-g711 to non-g711 will still work. This reservation
will take place even if this xcoding case doesn't exist.

Hence, I always recommend to avoid it if you know that you have one call
leg as g711. For better design.

**** please remember to rate useful posts