Changing Payload Type on outbound INVITE

Unanswered Question
Feb 6th, 2009

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:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK921A5E

Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off

From: <sip:[email protected]>;tag=47B1B10-19E4

To: <sip:[email protected]>

Date: Fri, 06 Feb 2009 21:31:42 GMT

Call-ID: [email protected]

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:[email protected]: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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Nicholas Matthews Fri, 02/06/2009 - 15:19

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

TIMOTHY DAVIDSON Mon, 02/09/2009 - 06:40

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

Nicholas Matthews Mon, 02/09/2009 - 07:20

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

TIMOTHY DAVIDSON Mon, 02/09/2009 - 10:11

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.

TIMOTHY DAVIDSON Tue, 02/10/2009 - 05:56

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.

Nicholas Matthews Tue, 02/10/2009 - 06:44

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

Actions

This Discussion