02-06-2009 02:26 PM - last edited on 03-25-2019 07:47 PM by ciscomoderator
I'm attempting to change the NTE(DTMF) payload type to 100 (from the default of 101) on my outbound calls. I've specified this in the dial-peers, but it seems to ignore me. Here is the outbound dial-peer (this is a H323-SIP CUBE):
dial-peer voice 10 voip
description GC SIP Trunk
translation-profile outgoing Strip9
destination-pattern 9T
rtp payload-type nse 105
rtp payload-type nte 100
voice-class codec 1
session protocol sipv2
session target ipv4:1.1.1.1:5060
dtmf-relay rtp-nte
no vad
But, here is the INVITE:
INVITE sip:19999999999@1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK921A5E
Remote-Party-ID: <sip:8889999999@2.2.2.2>;party=calling;screen=yes;privacy=off
From: <sip:8889999999@2.2.2.2>;tag=47B1B10-19E4
To: <sip:199999999@1.1.1.1>
Date: Fri, 06 Feb 2009 21:31:42 GMT
Call-ID: 6148E4A4-F3CC11DD-8140BBA0-F5C4DFFD@2.2.2.2
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 6056397-2534600989-50331648-3232241418
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1233955902
Contact: <sip:8889999999@2.2.2.2:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 229
v=0
o=CiscoSystemsSIP-GW-UserAgent 4792 7514 IN IP4 2.2.2.2
s=SIP Call
c=IN IP4 2.2.2.2
t=0 0
m=audio 16794 RTP/AVP 0 18
c=IN IP4 2.2.2.2
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
Cisco TAC seems to be stumped. Any ideas?
Thanx,
-Tim
02-06-2009 03:19 PM
Hi Tim,
The configuration looks fine. I would be more suspicious if you're actually hitting this dial peer now.
You can 'debug voip ccapi inout' or get 'show call active voice brief'.
Maybe try taking rtp-nte off and putting it back on. It may not have sync'd correctly after changing the payload type.
What IOS version are you on?
Can you post 'show dial-peer voice 10' and 'show run | s voice service'?
-nick
02-09-2009 06:40 AM
IOS Version 12.4(15)XY4 (recommended by TAC)
I've applied/re-applied/rebooted/etc with no luck. It just seems that the early-offer force is not fully implemented. It just ignores those payload-type commands on the outbound dial-peer.
VoiceOverIpPeer10
peer type = voice, system default peer = FALSE, information type = voice,
description = `GC SIP Trunk',
tag = 10, destination-pattern = `9T',
voice reg type = 0, corresponding tag = 0,
allow watch = FALSE
answer-address = `', preference=0,
CLID Restriction = None
CLID Network Number = `'
CLID Second Number sent
CLID Override RDNIS = disabled,
rtp-ssrc mux = system
source carrier-id = `', target carrier-id = `',
source trunk-group-label = `', target trunk-group-label = `',
numbering Type = `unknown'
group = 10, Admin state is up, Operation state is up,
incoming called-number = `', connections/maximum = 0/unlimited,
DTMF Relay = enabled,
modem transport = system,
in bound application associated: 'DEFAULT'
out bound application associated: ''
Translation profile (Incoming):
Translation profile (Outgoing):Strip9
incoming call blocking:
translation-profile = `'
disconnect-cause = `no-service'
advertise 0x40 capacity_update_timer 25 addrFamily 4 oldAddrFamily 4
type = voip, session-target = `ipv4:2.2.2.2:5060',
technology prefix:
settle-call = disabled
ip media DSCP = ef, ip signaling DSCP = af31,
session-protocol = sipv2, session-transport = system,
dtmf-relay = rtp-nte,
RTP dynamic payload type values: NTE = 100
Cisco: NSE=105, fax=96, fax-ack=97, dtmf=121, fax-relay=122
CAS=123, TTY=119, ClearChan=125, PCM switch over u-law=0,
A-law=8, GSMAMR-NB=117 iLBC=116, lmr_tone=115, nte_tone=0
h263+=118, h264=119
G726r16 using static payload
G726r24 using static payload
RTP comfort noise payload type = 19
fax rate = fax, payload size = 20 bytes
fax protocol = system
fax-relay ecm enable
Fax Relay SG3-to-G3 Enabled (by system configuration)
fax NSF = 0xAD0051 (default)
voice-class codec = 1
codec = g729r8, payload size = 20 bytes,
video codec = None
voice class codec = 1
text relay = disabled
Media Setting = flow-through (global)
Expect factor = 10, Icpif = 20,
Playout Mode is set to adaptive,
Initial 60 ms, Max 1000 ms
Playout-delay Minimum mode is set to default, value 40 ms
Fax nominal 300 ms
Max Redirects = 1, signaling-type = cas,
VAD = disabled, Poor QOV Trap = disabled,
Source Interface = NONE
tvoice class sip outbound-proxy = system,
voice class sip asserted-id = system,
voice class sip privacy = system,
voice class sip e911 = system,
voice class sip early-offer forced = system,
voice class sip negotiate cisco = system,
redirect ip2ip = disabled
local peer = false
probe disabled,
Secure RTP: system (use the global setting)
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
h323
h225 display-ie ccm-compatible
sip
bind control source-interface Loopback1
bind media source-interface Loopback1
early-offer forced
!
Very odd. I'll keep pushing with TAC.
Thanx
02-09-2009 07:20 AM
You may want to try 12.4(22)T. A lot of the CUBE commands like 'early-offer forced' have been polished in 20T and 22T.
-nick
02-09-2009 10:11 AM
I tried 22T and now the SDP information is not included at all, completely ignoring the early-offer forced. Nice polish. :)
I'll hammer on it and see if there was something else added that could help.
Thanx.
02-09-2009 10:43 AM
You may want to make sure that the call flow you're attempting is supported.
Here's the restriction list for H323-SIP:
http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb-gw-h323sip.html#wp1312731
-nick
02-10-2009 05:56 AM
Working with TAC, we found that the SDP information is not sent on the SIP leg unless you use Faststart on the outbound H323 leg from UCM. Bummer. The SDP information being sent before was actually the result of a bug CSCsq83476. :)
I'm really hoping Cisco got SIP right in 7.x so you it do SIP trunks properly.
Thanx for the input.
02-10-2009 06:44 AM
Yes - if you do early offer forced without fast start from the H323 side then that is called "slow start to early media" which I believe is in the restriction list.
Funny enough - it was a 'polish' because of a bug.
Using fast start with CUBE gets around many, many media problems with a H323-SIP CUBE. Some of the media transactions don't map very well, and having early media/fast start fixes many of those issues. Unfortunately this requires the use of an MTP.
I think CUCM 7.x has done quite a bit of work on their SIP trunking.
Good luck to you.
-nick
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: