[cisco-voip] DTMF conversion paired with transcoding functionality - C3945E

Maciej Bylica mbsip at gazeta.pl
Sat Jul 23 17:46:43 EDT 2011


Hi Nick

Thanks for prompt answer.
At first i need to upgrade IOS to sth 15.1.4M(ED), 15.1.3T1(ED) and then retest.
But now i know that there is no way to differentiate these calls.

Thx,
Maciej.

> I don't think you will be able to differentiate between calls that
> need DTMF conversions and those that don't.  Both types will hit the
> same dial peers.  Unless some come in with different codecs than the
> others, you'll use the transcoder any time there is a codec mismatch.
> I don't think it will invoke the transcoder for a dtmf mismatch.
> Should be something you can test in the lab though.
>
> -nick
>
> On Thu, Jul 21, 2011 at 5:11 PM, Maciej Bylica <mbsip at gazeta.pl> wrote:
>> Hello,
>>
>> I have CUBE 3945E running IOS ver 15.1.
>> I've been trying to configure hw transcoding and dialpeers to have
>> codec/dtmf/fax transcoding capabilities up and running.
>> Transcoding section looks like following:
>>
>>
>> voice-card 0
>>  dsp services dspfarm
>> !
>> voice service voip
>>  address-hiding
>>  allow-connections sip to sip
>>  no supplementary-service sip moved-temporarily
>>  no supplementary-service sip refer
>>  fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback
>> pass-through g711alaw
>>  sip
>>  midcall-signaling passthru
>> !
>> voice class codec 1
>>  codec preference 1 g729br8
>>  codec preference 2 g729r8
>>  codec preference 3 g711alaw
>> !
>> voice class codec 2
>>  codec preference 1 g711alaw
>>  codec preference 2 g711ulaw
>>
>> sccp local GigabitEthernet0/0
>> sccp ccm 10.10.10.3 identifier 1 version 4.0
>> sccp
>> !
>> sccp ccm group 48
>>  description testowy
>>  bind interface GigabitEthernet0/0
>>  associate ccm 1 priority 1
>>  associate profile 20 register sxcoder
>>  keepalive retries 5
>>  switchover method immediate
>>  switchback method immediate
>>  switchback interval 15
>> !
>> dspfarm profile 20 transcode universal
>>  description testow dsp profil
>>  codec g729abr8
>>  codec g729ar8
>>  codec g729r8
>>  codec g729br8
>>  codec g711alaw
>>  codec g711ulaw
>>  maximum sessions 15
>>  associate application SCCP
>> !
>> telephony-service
>>  sdspfarm units 1
>>  sdspfarm transcode sessions 128
>>  sdspfarm tag 1 sxcoder
>>  max-ephones 1
>>  max-dn 1
>>  ip source-address 10.10.10.3 port 2000
>>  max-conferences 1 gain -6
>>  transfer-system full-consult
>>
>> and it works.
>> The problem i have is associated somehow with DTMF conversion from
>> RFC2833 to G711 inband.
>>
>> !
>> dial-peer voice 1 voip
>>  description INCOMING dial-peer
>>  destination-pattern 4822T
>>  session protocol sipv2
>>  session target ipv4:10.10.10.2
>>  voice-class codec 1
>>  dtmf-relay rtp-nte
>> !
>> dial-peer voice 2 voip
>>  description OUTGOING dial-peer
>>  destination-pattern 4855+
>>  session protocol sipv2
>>  session target ipv4:10.10.10.4
>>  voice-class codec 2
>>  fax protocol pass-through g711alaw
>> !
>>
>> All calls matched with dialpeer 1 and 2 are being transcoded.
>> It doesn't matter if there are no dtmfs running back and forth.
>> Is there any chance to differentiate that behavior and for pure voice
>> call (without dtmf signals) do not use transcoding (while codec G.711
>> to codec G.711) but only for ivr type of connections where dmtfs are
>> needed?
>> Lets assume that we cannot differentiate dialpeers by callig/called number.
>>
>> What is more interesting i've just use Inband dtmf in inband call
>> attempt and transcoding was triggered exactly as previously.
>>
>> What did I miss?
>>
>> Thanks in advance.
>> Maciej.
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>



More information about the cisco-voip mailing list