10-23-2012 11:39 AM - edited 03-16-2019 01:50 PM
Hi all,
I have a couple of IAD 243x (specifically IAD2431 and IAD2432) running IOS 15.1(4)M5 that I'm using as SIP to E1 PRI ISDN gateways. They're configured with one POTS dial-peer for the ISDN and a couple of VoIP dial-peers depending on the incoming called number from the ISDN. This has been working fine with G.711 A-law end-to-end, but now I'm trying to get it to work with iLBC and having problems.
My dial-peer configuration looks like this:
dial-peer voice 1 pots
description Peer for ISDN30
translation-profile incoming inbound-from-bt
service session
destination-pattern .T
progress_ind alert strip 8
no digit-strip
direct-inward-dial
port 1/0:15
forward-digits all
!
dial-peer voice 3 voip
tone ringback alert-no-PI
description Peer for bearer number
huntstop
service session
destination-pattern 01234567890
rtp payload-type nte-tone 102
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4:1.2.3.4:5060
voice-class codec 1
dtmf-relay rtp-nte digit-drop
ip qos dscp cs3 signaling
clid network-provided
clid substitute name
!
dial-peer voice 65008 voip
tone ringback alert-no-PI
description Peer for main range
huntstop
service session
destination-pattern 01234567[1-8].
rtp payload-type nte-tone 102
rtp payload-type comfort-noise 13
session protocol sipv2
session target ipv4:1.2.3.4:5060
voice-class codec 1
dtmf-relay rtp-nte digit-drop
ip qos dscp cs3 signaling
clid network-provided
clid substitute name
Other relevant config:
voice rtp send-recv
!
voice service pots
rtcp keepalive
!
voice service voip
ip address trusted list
ipv4 1.2.3.4
rtcp keepalive
dtmf-interworking standard
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
sip
transport switch udp tcp
no anat
block 183 sdp present
!
voice class codec 1
codec preference 1 ilbc mode 30
codec preference 2 g729r8
codec preference 3 g711alaw
!
Now, when I place a call from ISDN through the gateway, the SDP it offers to my SBC is:
v=0
o=CiscoSystemsSIP-GW-UserAgent 7963 1810 IN IP4 6.7.8.9
s=SIP Call
c=IN IP4 6.7.8.9
t=0 0
m=audio 18710 RTP/AVP 116 18 8 101 13
c=IN IP4 6.7.8.9
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=30
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
This is great - both ends agree iLBC and the call comes up. However, if I make a call from the SIP side through to the ISDN, I offer this:
v=0
o=- 78207127932020 78207127932020 IN IP4 1.2.3.4
s=-
c=IN IP4 1.2.3.4
t=0 0
m=audio 24132 RTP/AVP 110 8 127
a=rtpmap:110 iLBC/8000
a=rtpmap:127 telephone-event/8000
a=fmtp:110 mode=30
a=silenceSupp:on - - - -
a=ptime:20
It then gives me a 200 OK with this:
v=0
o=CiscoSystemsSIP-GW-UserAgent 9977 8349 IN IP4 6.7.8.9
s=SIP Call
c=IN IP4 6.7.8.9
t=0 0
m=audio 17650 RTP/AVP 8 127
c=IN IP4 6.7.8.9
a=rtpmap:8 PCMA/8000
a=rtpmap:127 telephone-event/8000
a=fmtp:127 0-16
a=ptime:20
This means we use G.711 A-Law. If I remove this from the offer and just propose iLBC, the IAD rejects the call request.
Clearly it supports calls using G.711 over the ISDN and iLBC on the SIP side - how do I persuade it to allow calls initiated from the SIP side to work as well as calls initiated from the ISDN side?
Many thanks in advance for any suggestions!
Sean
Solved! Go to Solution.
10-23-2012 12:59 PM
You should have "incoming called-number ." under voip DP.
10-23-2012 12:59 PM
You should have "incoming called-number ." under voip DP.
10-23-2012 01:05 PM
OK, thanks - are you saying the incoming SIP call isn't matching one of the VoIP DPs so it's not picking up the codec config?
10-23-2012 04:06 PM
Paolo is correct; you're matching dial-peer 0 since there is nothing to match the incoming VOIP dial-peer on. In addition to the methods outlined in that document you can now also match based on the SIP URI.
Once you have added the command you can use the 'debug call active voice brief' command. The output will show the matched dialpeers. The pid will be the dial-peer tag number; if you see pid : 0 you're on dial-peer 0.
Please remember to rate helpful responses and identify helpful or correct answers.
10-24-2012 04:40 AM
Thanks, that fixed it I've now got a different issue with the IAD tearing the call down when it's put on hold on the SIP side with Q.850 release cause 172 and a '%HPI-3-FAILED_START: channel:1/0:15 DSP ID:0x2, failed mode 1 for service 27' log - we have a Music On Hold server that only does G.711, so it seems to be an issue switching codecs during the call. I'll create a separate thread for this though...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide