[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