[nsp] VOIP Problem - Issue with PRI and NM-HDV again
Bender, Andrew
abender at taqua.com
Wed Feb 19 12:08:35 EST 2003
I think you'll find that this is actually correct, given the resolution you stated.
PLAR is not a valid configuration for PRI unless non-enbloc (i.e. overlap) signaling is supported- this is not common stateside. With your current configuration, you would have sent either a "9" or nothing in the PRI setup msg; neither are the complete E.164 that your provider is expecting.
Regards,
Andrew Bender
taqua.com
> -----Original Message-----
> From: Cisco Geek Rotation [mailto:cisco at peakpeak.com]
> Sent: Tuesday, February 18, 2003 7:27 PM
> To: Bender, Andrew
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [nsp] VOIP Problem - Issue with PRI and NM-HDV again
>
>
> At 06:12 PM 2/18/2003 -0500, Bender, Andrew wrote:
> >It looks like you are sending simply a "9" down the PRI in the setup
> >message, instead of a full DN/E.164 that the far end is
> probably expecting.
>
>
> Actually, no. What used to happen is when you dialed a "9"
> it would pull
> the FXO line off hook. Then, you could enter the digits for
> the actual
> call. 9 was just a signal to the router on which dial pots
> peer to invoke,
> it wasn't required to dial a 9 to access an outside line.
>
> After you dialed 9 and Mr. Dialtone was invoked, you would
> then dial the
> number you were calling. Now what happens is you dial 9 and
> that digit is
> not properly transmitted to the telco.
>
> If I put destination-pattern 8195551212 the call won't
> complete either, it
> will give an error message still. So there is something more
> basic wrong here.
>
> Chris
>
>
>
> >You might have had a centrex service on the FXS that you had
> before (which
> >might allow the '9', or special dialing plan, etc). It is
> somewhat unusual
> >for Centrex dialing plans to be configured on the PRI, or
> your LEC might
> >not even support that, so be sure to check with them...
> >
> >Good Luck,
> >Andrew Bender
> >taqua.com
> >
> > > -----Original Message-----
> > > From: Cisco Geek Rotation [mailto:cisco at peakpeak.com]
> > > Sent: Tuesday, February 18, 2003 2:15 PM
> > > To: cisco-nsp at puck.nether.net
> > > Subject: [nsp] VOIP Problem - Issue with PRI and NM-HDV again
> > >
> > >
> > >
> > > I finally got inbound calls on this PRI to work. The telco had a
> > > problem. That never happens, I know.
> > >
> > > So now that calls are coming in OK I am trying to make calls
> > > out. The way
> > > I used to do this with the FXS/FXO cards that are in this
> > > 3662 is I'd dial
> > > 9 on a FXS station, and the FXO pots line would be pulled off
> > > hook so that
> > > I can dial a call into the PSTN.
> > >
> > > That no longer works since I converted from FXO/FXS cards to
> > > the FXS card
> > > on the phone with a NM-HDV card and the PRI. The telco says
> > > the PRI is
> > > two-way so that it should work. But when I dial 9 nothing
> > > useful happens,
> > > just a telco error message "Sorry your call cannot be
> > > completed as dialed."
> > >
> > > Old way:
> > >
> > > phone ---- FXS in 3662 ---- FXO in 3662 --- PSTN
> > >
> > > New way:
> > >
> > > phone --- FXS in 3662 ---- NM-HDV with PRI in 3662 ----- PSTN
> > >
> > >
> > > Here is the new way config:
> > >
> > > controller T1 6/0
> > > framing esf
> > > linecode b8zs
> > > pri-group timeslots 1-24
> > > !
> > > interface Serial6/0:23
> > > no ip address
> > > no logging event link-status
> > > isdn switch-type primary-ni
> > > isdn incoming-voice voice
> > > no cdp enable
> > > !
> > > voice-port 6/0:23
> > > no comfort-noise
> > > connection plar 1
> > > !
> > > dial-peer voice 10 pots
> > > destination-pattern 9
> > > port 6/0:23
> > > !
> > >
> > > I thought maybe that int Ser6/0:23 needed to have an isdn
> > > outgoing-voice
> > > statement but that didn't seem to help anything.
> > >
> > > So I turned on debug voice ccapi inout to view the debugs.
> > >
> > > I pulled the FXS station off-hook and get the debugs shown
> > > here. Any ideas
> > > on what to look for? I don't really understand why it says
> > > "DEFAULT" about
> > > 6 lines down here. I haven't dialed any digits at that point.
> > >
> > > Feb 18 19:12:32.885: cc_api_call_setup_ind (vdbPtr=0x62E25E1C,
> > > callInfo={called=,called_oct3=0x81,calling=,calling_oct3=0x0,c
> > > alling_oct3a=0x0,calling_xlated=false,subscriber_type_str=Regu
> > > larLine,fdest=0,peer_tag=0,
> > > prog_ind=3},callID=0x629F2F0C)
> > > Feb 18 19:12:32.885: cc_api_call_setup_ind type 3 , prot 0
> > > Feb 18 19:12:32.889: cc_process_call_setup_ind (event=0x62DE0930)
> > > Feb 18 19:12:32.889: >>>>CCAPI handed cid 1567 with tag 0 to
> > > app "DEFAULT"
> > > Feb 18 19:12:32.889: sess_appl: ev(24=CC_EV_CALL_SETUP_IND),
> > > cid(1567), disp(0)
> > > Feb 18 19:12:32.889: sess_appl: ev(SSA_EV_CALL_SETUP_IND),
> > > cid(1567), disp(0)
> > > Feb 18 19:12:32.889: ssaCallSetupInd
> > > Feb 18 19:12:32.889: ccCallSetContext (callID=0x61F,
> > > context=0x63CC7384)
> > > Feb 18 19:12:32.889: ssaCallSetupInd cid(1567),
> > > st(SSA_CS_MAPPING),oldst(0),
> > > ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 0
> > > Feb 18 19:12:32.889: ccCallSetupAck (callID=0x61F)
> > > Feb 18 19:12:32.889: ccGenerateTone (callID=0x61F tone=8)
> > > Feb 18 19:12:32.889: ccCallReportDigits (callID=0x61F, enable=0x1)
> > > Feb 18 19:12:32.889: cc_api_call_report_digits_done
> > > (vdbPtr=0x62E25E1C,
> > > callID=0x61F, disp=0)
> > > Feb 18 19:12:32.889: sess_appl:
> ev(52=CC_EV_CALL_REPORT_DIGITS_DONE),
> > > cid(1567), disp(0)
> > > Feb 18 19:12:32.889:
> > > cid(1567)st(SSA_CS_MAPPING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE)
> > > oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
> > > Feb 18 19:12:32.889: ssaReportDigitsDone cid(1567) peer
> list: (empty)
> > > Feb 18 19:12:32.889: ssaReportDigitsDone callid=1567
> Enable succeeded
> > > Feb 18 19:12:32.889: ccGenerateTone (callID=0x61F tone=8)
> > > router#
> > > router#
> > > router#
> > >
> > > I dialed a "9" here and get:
> > >
> > > router#
> > > router#
> > > Feb 18 19:12:40.177: cc_api_call_digit_begin (dstVdbPtr=0x0,
> > > dstCallId=0xFFFFFFFF, srcCallId=0x61F,
> > > digit=9, digit_begin_flags=0x1, rtp_timestamp=0xD5A75BC4
> > > rtp_expiration=0x0, dest_mask=0x1)
> > > Feb 18 19:12:40.177: sess_appl:
> > > ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(1567),
> > > disp(0)
> > > Feb 18 19:12:40.177:
> cid(1567)st(SSA_CS_MAPPING)ev(SSA_EV_DIGIT_BEGIN)
> > > oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
> > > Feb 18 19:12:40.177: ssaIgnore cid(1567),
> > > st(SSA_CS_MAPPING),oldst(0), ev(10)
> > > Feb 18 19:12:40.229: cc_api_call_digit_end (dstVdbPtr=0x0,
> > > dstCallId=0xFFFFFFFF, srcCallId=0x61F,
> > > digit=9,duration=100,xruleCallingTag=0,xruleCalledTag=0,
> > > dest_mask=0x1)
> > > Feb 18 19:12:40.229: sess_appl: ev(9=CC_EV_CALL_DIGIT_END),
> > > cid(1567), disp(0)
> > > Feb 18 19:12:40.229:
> cid(1567)st(SSA_CS_MAPPING)ev(SSA_EV_CALL_DIGIT)
> > > oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
> > > Feb 18 19:12:40.229: ssaDigit
> > > Feb 18 19:12:40.229: ssaDigit, 0. sct->digit , sct->digit len
> > > 0,usrDigit 9
> > >
> > > Feb 18 19:12:40.229: ssaDigit,1. callinfo.called , digit 9,
> > > callinfo.calling , xrulecallingtag 0, xrulecalledtag 0
> > > Feb 18 19:12:40.229: ssaDigit, 7. callinfo.calling ,
> > > sct->digit 9, result 0
> > > Feb 18 19:12:40.229: ccCallReportDigits (callID=0x61F, enable=0x0)
> > > Feb 18 19:12:40.229: cc_api_call_report_digits_done
> > > (vdbPtr=0x62E25E1C,
> > > callID=0x61F, disp=0)
> > > Feb 18 19:12:40.229: ssaSetupPeer cid(1567) peer list:
> > > tag(10) called
> > > number (9)
> > > Feb 18 19:12:40.229: ssaSetupPeer cid(1567), destPat(9),
> matched(1),
> > > prefix(), peer(63954794), peer->encapType (1)
> > > Feb 18 19:12:40.229: ccCallProceeding (callID=0x61F, prog_ind=0x0)
> > > Feb 18 19:12:40.229: ccCallSetupRequest (Inbound call =
> > > 0x61F, outbound
> > > peer =10, dest=,
> > > params=0x62DE7298 mode=0, *callID=0x62DE7600,
> prog_ind = 3)
> > > Feb 18 19:12:40.229: ccCallSetupRequest numbering_type 0x81
> > > Feb 18 19:12:40.229: dest pattern 9, called 9, digit_strip 1
> > > Feb 18 19:12:40.229: callingNumber=, calledNumber=9,
> redirectNumber=
> > > display_info= calling_oct3a=0
> > > Feb 18 19:12:40.229: accountNumber=, finalDestFlag=0,
> > > guid=c42d.1edd.42ab.11d7.8998.dd6d.d6bb.3823
> > > Feb 18 19:12:40.229: peer_tag=10
> > > Feb 18 19:12:40.229: ccIFCallSetupRequestPrivate:
> (vdbPtr=0x62A99A04,
> > > dest=, callParams={called=9,called_oct3=0x81,
> > > calling=,calling_oct3=0x0,
> > > calling_xlated=false, subscriber_type_str=RegularLine, fdest=0,
> > > voice_peer_tag=10},mode=0x0) vdbPtr type = 6
> > > Feb 18 19:12:40.229: ccIFCallSetupRequestPrivate:
> (vdbPtr=0x62A99A04,
> > > dest=, callParams={called=9, called_oct3 0x81,
> > > calling=,calling_oct3 0x0,
> > > calling_xlated=false, fdest=0, voice_peer_tag=10}, mode=0x0,
> > > xltrc=-5)
> > > Feb 18 19:12:40.229: ccSaveDialpeerTag (callID=0x61F,
> dialpeer_tag=
> > > Feb 18 19:12:40.229: ccCallSetContext (callID=0x620,
> > > context=0x63CC7818)
> > > Feb 18 19:12:40.229: sess_appl:
> ev(52=CC_EV_CALL_REPORT_DIGITS_DONE),
> > > cid(1567), disp(0)
> > > Feb 18 19:12:40.229:
> > > cid(1567)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE)
> > > oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
> > > Feb 18 19:12:40.229:
> > > -cid2(1568)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING)
> > > Feb 18 19:12:40.229: ssaReportDigitsDone cid(1567) peer
> list: (empty)
> > > Feb 18 19:12:40.229: ssaReportDigitsDone callid=1567
> > > Reporting disabled.
> > > Feb 18 19:12:40.285:
> > > cc_api_call_proceeding(vdbPtr=0x62A99A04, callID=0x620,
> > > prog_ind=0x0)
> > > Feb 18 19:12:40.285: sess_appl: ev(21=CC_EV_CALL_PROCEEDING),
> > > cid(1568),
> > > disp(0)
> > > Feb 18 19:12:40.285:
> > > cid(1568)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_PROCEEDING)
> > > oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(0)fDest(0)
> > > Feb 18 19:12:40.285:
> > > -cid2(1567)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)
> > > Feb 18 19:12:40.285: ssaCallProc
> > > Feb 18 19:12:40.285: ccGetDialpeerTag (callID=0x61F)
> > > Feb 18 19:12:40.285: ssaIgnore cid(1568),
> > > st(SSA_CS_CALL_SETTING),oldst(1),
> > > ev(21)
> > > Feb 18 19:12:40.569: cc_api_call_cut_progress(vdbPtr=0x62A99A04,
> > > callID=0x620, prog_ind=0x8, sig_ind=0x2)
> > > Feb 18 19:12:40.573: sess_appl: ev(22=CC_EV_CALL_PROGRESS),
> > > cid(1568), disp(0)
> > > Feb 18 19:12:40.573:
> > > cid(1568)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_PROGRESS)
> > > oldst(SSA_CS_CALL_SETTING)cfid(-1)csize(0)in(0)fDest(0)
> > > Feb 18 19:12:40.573:
> > > -cid2(1567)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)
> > > Feb 18 19:12:40.573: ssaCutProgress
> > > Feb 18 19:12:40.573: ccGetDialpeerTag (callID=0x61F)
> > > Feb 18 19:12:40.573: ccCallCutProgress (callID=0x61F,
> prog_ind=0x8,
> > > sig_ind=0x2)
> > > Feb 18 19:12:40.573: ccConferenceCreate (confID=0x62DE79C4,
> > > callID1=0x61F,
> > > callID2=0x620, tag=0x0)
> > > Feb 18 19:12:40.573: cc_api_bridge_done (confID=0x2FE,
> > > srcIF=0x62E25E1C,
> > > srcCallID=0x61F, dstCallID=0x620, disposition=0, tag=0x0)
> > > Feb 18 19:12:40.573: cc_api_caps_ind (dstVdbPtr=0x62A99A04,
> > > dstCallId=0x620, srcCallId=0x61F,
> > > caps={codec=0x1, fax_rate=0x1, vad=0x2, modem=0x2
> > > codec_bytes=80, signal_type=2})
> > > Feb 18 19:12:40.573: cc_api_caps_ind (Playout: mode 0,
> > > initial 60,min 40,
> > > max 300)
> > > Feb 18 19:12:40.573: cc_api_bridge_done (confID=0x2FE,
> > > srcIF=0x62A99A04,
> > > srcCallID=0x620, dstCallID=0x61F, disposition=0, tag=0x0)
> > > Feb 18 19:12:40.573: cc_api_caps_ind (dstVdbPtr=0x62E25E1C,
> > > dstCallId=0x61F, srcCallId=0x620,
> > > caps={codec=0x1, fax_rate=0x1, vad=0x2, modem=0x2
> > > codec_bytes=80, signal_type=2})
> > > Feb 18 19:12:40.573: cc_api_caps_ind (Playout: mode 0,
> > > initial 60,min 40,
> > > max 300)
> > > Feb 18 19:12:40.573: cc_api_caps_ack (dstVdbPtr=0x62E25E1C,
> > > dstCallId=0x61F, srcCallId=0x620,
> > > caps={codec=0x1, fax_rate=0x1, vad=0x2, modem=0x2
> > > codec_bytes=80, signal_type=2, seq_num_start=9003})
> > > Feb 18 19:12:40.573: cc_api_caps_ack (dstVdbPtr=0x62A99A04,
> > > dstCallId=0x620, srcCallId=0x61F,
> > > caps={codec=0x1, fax_rate=0x1, vad=0x2, modem=0x2
> > > codec_bytes=80, signal_type=2, seq_num_start=4147})
> > > Feb 18 19:12:40.573: cc_api_voice_mode_event , callID=0x61F
> > > Feb 18 19:12:40.573: Call Pointer =63CC7384
> > > Feb 18 19:12:40.573: cc_api_voice_mode_event , callID=0x620
> > > Feb 18 19:12:40.573: Call Pointer =63CC7818
> > > Feb 18 19:12:40.573: sess_appl:
> > > ev(29=CC_EV_CONF_CREATE_DONE), cid(1567),
> > > disp(0)
> > > Feb 18 19:12:40.573:
> > >
> cid(1567)st(SSA_CS_CONFERENCING_PROGRESS)ev(SSA_EV_CONF_CREATE_DONE)
> > > oldst(SSA_CS_CALL_SETTING)cfid(766)csize(0)in(1)fDest(0)
> > > Feb 18 19:12:40.573:
> > > -cid2(1568)st2(SSA_CS_CONFERENCING_PROGRESS)oldst2(SSA_CS_CALL
> > > _SETTING)
> > > Feb 18 19:12:40.573: ssaConfCreateDoneAlert
> > > Feb 18 19:12:40.573: sess_appl: ev(50=CC_EV_VOICE_MODE_DONE),
> > > cid(1567),
> > > disp(0)
> > > Feb 18 19:12:40.573:
> > > cid(1567)st(SSA_CS_CONFERENCED_ALERT)ev(SSA_EV_VOICE_MODE_DONE)
> > > oldst(SSA_CS_CONFERENCING_PROGRESS)cfid(766)csize(0)in(1)fDest(0)
> > > Feb 18 19:12:40.573:
> > >
> -cid2(1568)st2(SSA_CS_CONFERENCED_ALERT)oldst2(SSA_CS_CALL_SETTING)
> > > Feb 18 19:12:40.573: ssaIgnore cid(1567),
> > > st(SSA_CS_CONFERENCED_ALERT),oldst(4), ev(50)
> > > Feb 18 19:12:40.573: sess_appl: ev(50=CC_EV_VOICE_MODE_DONE),
> > > cid(1568),
> > > disp(0)
> > > Feb 18 19:12:40.573:
> > > cid(1568)st(SSA_CS_CONFERENCED_ALERT)ev(SSA_EV_VOICE_MODE_DONE)
> > > oldst(SSA_CS_CALL_SETTING)cfid(766)csize(0)in(0)fDest(0)
> > > Feb 18 19:12:40.573:
> > > -cid2(1567)st2(SSA_CS_CONFERENCED_ALERT)oldst2(SSA_CS_CONFEREN
> > > CED_ALERT)
> > > Feb 18 19:12:40.573: ssaIgnore cid(1568),
> > > st(SSA_CS_CONFERENCED_ALERT),oldst(4), ev(50)
> > > Feb 18 19:12:40.573: cc_process_notify_bridge_done
> (event=0x62DD92B0)
> > >
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> >
> >_______________________________________________
> >cisco-nsp mailing list cisco-nsp at puck.nether.net
> >http://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
More information about the cisco-nsp
mailing list