cme - media negotiation fails

[Peter Fiers]

Hi,

I'm doing SIP trunking with the german voice provider QSC. You can find the config and the version data below. In some points it works fine, but dialing in from somewhere else (e.g. mobile) than from a fixed line of the Deutsche Telekom doesn't work. I get messages and errors about failed media negotiation. But I can't see any difference in the INVITE message as compared to successful calls. Can you please tell me what goes wrong and how to fix it? Attached are files with debugs (messages, media, error) of both the unsuccessful and the successful communication, and an on-the-wire trace of the unsuccessful communication. Thanks.

Cisco 2811 (revision 53.50)

Cisco IOS Software, 2800 Software (C2800NM-IPVOICEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)

voice service voip

allow-connections sip to sip

sip

registrar server expires max 600 min 60

!

voice register global

mode cme

source-address 192.168.0.100 port 5060

max-dn 144

max-pool 42

load 7960-7940 P0S3-08-9-00

authenticate register

timezone 23

time-format 24

date-format D/M/Y

bulk 062211879000

tftp-path flash:

file text

create profile sync 0253240513247794

network-locale DE

user-locale DE

ntp-server 192.168.0.100 mode unicast

!

voice register dn 1

number 062211879000

!

voice register pool 1

id mac 0003.6B8B.1700

type 7960

number 1 dn 1

username username password password

no call-waiting

!

voice translation-rule 1

rule 5 /^[1-9]\(.*\)/ /06221&\1/

!

voice translation-rule 2

rule 5 /9.../ /062211879000/

!

voice translation-profile outward

translate calling 2

translate called 1

!

voice-card 0

no dspfarm

!

dial-peer voice 10 voip

translation-profile outgoing outward

destination-pattern .T

session protocol sipv2

session target sip-server

!

sip-ua

keepalive target dns:sip.qsc.de

authentication username username password 7 password realm qsc.de

timers keepalive active 300

registrar dns:sip.qsc.de expires 3600

sip-server dns:sip.qsc.de

!

telephony-service

max-conferences 8 gain -6

transfer-system full-consult

create cnf-files version-stamp Jan 01 2002 00:00:00

[pcameron]

This problem is likely due to codec interworking between the external SIP device and the version of IOS on the router. The call is getting rejected due to a codec mismatch. Since you do not have any 'incoming called-number' statement, the router would use the default dial peer which specifies G729.

There is a reasonably well known issue involving codec interworking that is due to Cisco defect CSCeh19375.

This DDTS was not specifically a bug, but it added IOS compliance for RFC 3555. RFC 3555 changes the way G729 is dealt with - the parameter "annexb" must be included in the SDP. In this case, the parameter is not included in the SDP from the SIP proxy and as a result, the router will try and use G729br8. This codec is not configured and the call fails.

As a fix, try adding G729br8 codec to a voice class codec and binding this to dial peer 10 by means of the command 'incoming called-number .'

!

voice class codec 1

codec preference 1 g729br8

codec preference 2 g711ulaw

codec preference 3 g711alaw

!

!

dial-peer voice 10 voip

incoming called-number . <---- add this

voice-class codec 1 <---- add this

translation-profile outgoing outward

destination-pattern .T

session protocol sipv2

session target sip-server

!

This will match the correct codec when the SIP Proxy attempts to use G729.

[Peter Fiers]

Hi,

thank you for answering.

There are two issues I might address:

1. The configuration you suggest results in rerouting the call to the SP. In this case there is no 488 problem, but it doesn't work either.

2. Does the line 'a=fmtp:18 annexb=yes' in the invite message from the SP not mean what you postulated above, that the parameter "annexb" be included in the SDP?

Besides, I've tried with an additional dial-peer like this:

dial-peer voice 20 voip

destination-pattern 062211879000

voice-class codec 1

session target ipv4:192.168.128.101

But this resulted in the same 488 media incompatibility message.

And last but not least: Why does it work from fixed line phones of the german telecom? The config is the same...

Thanks.