[cisco-voip] RTP only one way?
Eric Knudson
ericknudson at gmail.com
Fri May 6 09:52:23 EDT 2005
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a008009484b.shtml
More specifically, there's something in the routing engine that aids
in the correct creation of packetized voice in the dsps, if I remember
correctly.
On 5/6/05, Gerd Feiner <g.feiner at cablesurf.de> wrote:
> Hi Folks,
>
> I finally figured it out!!!
>
> For anyone running into the same trouble:
>
> The trick was to enable IP routing on the AS5350! It is apparently not
> enough to set ip default-gateway when no ip routing ist set, instead
> you have to enable ip routing and the set the default route with ip
> route 0.0.0.0 0.0.0.0 ... very puzzling behaviuor - since the AS could
> ping the ATA perfectly with only ip default-gateway set, but couldn't
> send an RTP-stream.
>
> Maybe someone can clarify this?
>
> Brgds,
> Gerd
>
> Am 04.05.2005 um 19:29 schrieb Gerd Feiner:
>
> > Hi Folks,
> >
> > what'ya make of this? (still no RTP from PSTN to SIP ...):
> >
> > 20:52.623: voip_rtp_create_session: callID=15, dstCallID=16
> > laddr=<AS5350>, lport=17388,raddr=<ATA>, rport=19058, type=3,
> > sig_tos=3, ip_tos=5
> > 20:52.623: voip_rtcp_get_cname: cname=0.0.0@<AS5350>
> > 20:52.623: voip_rtp_update_xmit_info
> > 20:52.623: voip_rtp_update_xmit_info, dstvdbptr: 6428AD08, dstCallID
> > 16, gccb: 64C10068, xmitFunc 61201000,context 0
> > 20:52.623: voip_rtp_update_xmit_info Context is NULL, exit
> > 20:52.623: voip_rtp_set_non_rtp_call: Non-RTP call end
> > 20:52.623: voip_rtp_exchange_context_info
> > 20:52.623: voip_rtp_update_xmit_info
> > 20:52.623: voip_rtp_update_xmit_info, dstvdbptr: 63E4BCB4, dstCallID
> > 16, gccb: 64C10068, xmitFunc 61201000,context 64BB6D28
> > 20:52.627: voip_rtp_update_xmit_info Xmit Info node current values
> > xmit_info->dstvdbptr: 63E4BCB4, xmit_info->dstCallID 16,
> > xmit_info->xmitFunc 61201000, xmit_info->context 64BB6D28
> > 20:52.627: voip xmit info count: 1
> > 20:52.627: voip_rtp_exchange_context_info
> > 20:52.627: voip_rtp_update_xmit_info
> > 20:52.627: voip_rtp_update_xmit_info, dstvdbptr: 6428AD08, dstCallID
> > 16, gccb: 64C10068, xmitFunc 61201000,context 64BB6D28
> > 20:52.627: voip_rtp_update_xmit_info Xmit Info node current values
> > xmit_info->dstvdbptr: 6428AD08, xmit_info->dstCallID 16,
> > xmit_info->xmitFunc 61201000, xmit_info->context 64BB6D28
> > 20:52.627: voip xmit info count: 1
> > 20:52.627: voip_rtp_exchange_context_info
> > 20:52.627: voip_rtp_update_xmit_info
> > 20:52.627: voip_rtp_update_xmit_info, dstvdbptr: 6428AD08, dstCallID
> > 16, gccb: 64C10068, xmitFunc 61201000,context 64BB6D28
> > 20:50 GMT^M Call-ID: 18dcfcb3-6ae7ce27@<ATA>^M Server:
> > Cisco-SIPGateway/IOS-12.x^M CSeq: 101 INVITE^M Allow-Events:
> > telephone-event^M Contact: <sip:<phone_nr>@<AS5350>:5060>^M
> > Content-Disposition: session;handling=required^M Content-Type:
> > application/sdp^M Content-Length: 197^M ^M v=0^M
> > o=CiscoSystemsSIP-GW-UserAgent 5378 1113 IN IP4 <AS5350>^M s=SIP
> > Call^M c=IN IP4 <AS5350>^M t=0 0^M m=audio 17388 RTP/AVP 0^M c=IN IP4
> > <AS5350>^M a=rtpmap:0 PCMU/8000^M a=ptime:20^M
> > 20:52.627: voip_rtp_update_xmit_info Xmit Info node current values
> > xmit_info->dstvdbptr: 6428AD08, xmit_info->dstCallID 16,
> > xmit_info->xmitFunc 61201000, xmit_info->context 64BB6D28
> > 20:52.627: voip xmit info count: 1
> > 20:52.627: voip_rtcp_start_session:
> > 20:52.627: voip_rtcp_start_session: start session
> >
> > Brgds,
> > Gerd
> >
> > Am 29.04.2005 um 19:30 schrieb Bryan Deaver:
> >
> >> Wow, you really scrubbed the config and debug output.
> >>
> >> From the show call active voice brief, it appears packets are being
> >> sent
> >> out, though at a rate smaller than the inbound rate. It appears that
> >> you
> >> don't have vad enabled on the sipura device where you do on the 5400.
> >> Add
> >> 'no vad' on dial-peer 2 and you should see fairly symmetrical output
> >> in the
> >> packet count.
> >>
> >> Your sip-ua command 'nat symmetric check-media-src' appears to better
> >> indicate what your typology looks like. Someone already mentioned
> >> that
> >> one-way audio is common in firewall/nat typologies. The usual
> >> symptom is
> >> that the audio works in the direction in->out but not out->in which I
> >> am
> >> guessing is going on in your configuration.
> >>
> >> Since we cannot see the addressing you are using, I recommend making
> >> sure
> >> that the address you see in the show and debug output match what you
> >> expect
> >> to happen. I also suggest that you get an ethereal trace before and
> >> after
> >> the NAT device and I expect that you will find the problem there.
> >>
> >> If you are still having issues, please open up a TAC case so that we
> >> can
> >> look more closely at the details of your setup in a less public forum.
> >>
> >> Bryan
> >>
> >>
> >>
> >>
> >>
> >>> From: Gerd Feiner <g.feiner at cablesurf.de>
> >>> Date: Fri, 29 Apr 2005 18:57:45 +0200
> >>> To: Bryan Deaver <bdeaver at cisco.com>
> >>> Cc: "<cisco-voip at puck.nether.net> <cisco-voip at puck.nether.net>"
> >>> <cisco-voip at puck.nether.net>
> >>> Subject: Re: [cisco-voip] RTP only one way?
> >>>
> >>> OK, here we go.
> >>>
> >>> #sh ver
> >>> Cisco Internetwork Operating System Software
> >>> IOS (tm) 5350 Software (C5350-IK9SU2-M), Version 12.3(13), RELEASE
> >>> SOFTWARE (fc2)
> >>> Technical Support: http://www.cisco.com/techsupport
> >>> Copyright (c) 1986-2005 by cisco Systems, Inc.
> >>> Compiled Thu 10-Feb-05 04:17 by ssearch
> >>> Image text-base: 0x60008AFC, data-base: 0x61880000
> >>>
> >>> ROM: System Bootstrap, Version 12.2(1r)1, RELEASE SOFTWARE (fc1)
> >>> BOOTLDR: 5350 Software (C5350-BOOT-M), Version 12.2(2)XB2, EARLY
> >>> DEPLOYMENT RELEASE SOFTWARE (fc1)
> >>>
> >>> mgw_muc_1 uptime is 1 day, 6 hours, 39 minutes
> >>> System returned to ROM by reload at 00:10:16 GMT Sat Jan 1 2000
> >>> System restarted at 12:14:08 GMT Thu Apr 28 2005
> >>> System image file is "flash:c5350-ik9su2-mz.123-13.bin"
> >>>
> >>>
> >>> This product contains cryptographic features and is subject to United
> >>> States and local country laws governing import, export, transfer and
> >>> use. Delivery of Cisco cryptographic products does not imply
> >>> third-party authority to import, export, distribute or use
> >>> encryption.
> >>> Importers, exporters, distributors and users are responsible for
> >>> compliance with U.S. and local country laws. By using this product
> >>> you
> >>> agree to comply with applicable laws and regulations. If you are
> >>> unable
> >>> to comply with U.S. and local laws, return this product immediately.
> >>>
> >>> A summary of U.S. laws governing Cisco cryptographic products may be
> >>> found at:
> >>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
> >>>
> >>> If you require further assistance please contact us by sending email
> >>> to
> >>> export at cisco.com.
> >>>
> >>> cisco AS5350 (R7K) processor (revision T) with 262144K/131072K bytes
> >>> of
> >>> memory.
> >>> Processor board ID JAE08512F9T
> >>> R7000 CPU at 250MHz, Implementation 39, Rev 1.0, 256KB L2, 2048KB L3
> >>> Cache
> >>> Last reset from IOS reload
> >>> Channelized E1, Version 1.0.
> >>> Bridging software.
> >>> X.25 software, Version 3.0.0.
> >>> SuperLAT software (copyright 1990 by Meridian Technology Corp).
> >>> Primary Rate ISDN software, Version 1.1.
> >>> Manufacture Cookie Info:
> >>> EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x32,
> >>> Board Hardware Version 3.34, Item Number 800-5171-02,
> >>> Board Revision C0, Serial Number JAE08512F9T,
> >>> PLD/ISP Version 2.2, Manufacture Date 14-Dec-2004.
> >>> Processor 0x14, MAC Address 0x012048F32E
> >>> Backplane HW Revision 1.0, Flash Type 5V
> >>> 2 FastEthernet/IEEE 802.3 interface(s)
> >>> 130 Serial network interface(s)
> >>> 120 terminal line(s)
> >>> 4 Channelized E1/PRI port(s)
> >>> 512K bytes of non-volatile configuration memory.
> >>> 65536K bytes of processor board System flash (Read/Write)
> >>> 16384K bytes of processor board Boot flash (Read/Write)
> >>>
> >>> Configuration register is 0x2102
> >>>
> >>> all the other information is attached in txt-files.
> >>>
> >>> Brgds,
> >>> Gerd
> >>>
> >>>
> >>>
> >>> Am 29.04.2005 um 18:36 schrieb Bryan Deaver:
> >>>
> >>>> OK, please get some debugs and show commands to better understand
> >>>> what
> >>>> is
> >>>> happening.
> >>>>
> >>>> For a _single_ call, gather the below debugs. Make sure that you
> >>>> have
> >>>> console logging disabled first and always nice to have timestamps
> >>>> set
> >>>> to
> >>>> msec.
> >>>> - debug ccsip message
> >>>> - debug ccsip events
> >>>> - debug isdn q931
> >>>> - debug voip ccapi inout
> >>>>
> >>>> Also, when the call is connected and in this one-way audio state,
> >>>> please get
> >>>> the output of 'show call active voice brief'.
> >>>>
> >>>> If you can please send the show version as well. The complete
> >>>> configuration
> >>>> would be good as well but you can send that privately if you want;
> >>>> with
> >>>> passwords removed.
> >>>>
> >>>> Bryan
> >>>>
> >>>>
> >>>>
> >>>>> From: Gerd Feiner <g.feiner at cablesurf.de>
> >>>>> Date: Fri, 29 Apr 2005 17:59:45 +0200
> >>>>> To: Kevin Thorngren <kevint at cisco.com>
> >>>>> Cc: "<cisco-voip at puck.nether.net> <cisco-voip at puck.nether.net>"
> >>>>> <cisco-voip at puck.nether.net>
> >>>>> Subject: Re: [cisco-voip] RTP only one way?
> >>>>>
> >>>>> Hi Kevin,
> >>>>>
> >>>>> no there aren't any routing issues. The AS can ping the sipura and
> >>>>> there are indeed RTP-packets from the AS to the sipura - about 1
> >>>>> every
> >>>>> two seconds, while there are many many packtes from the sipura to
> >>>>> the
> >>>>> AS5350 ... when debugging SIP the AS5350 also tells about opening a
> >>>>> recv-only audio-stream:
> >>>>>
> >>>>> Apr 29 12:41:56 x.x.x.x 42940: Apr 29 10:48:30.444:
> >>>>> sipSPIAddStream:
> >>>>> AddStream in idle state to open a 'recvonly' media session
> >>>>>
> >>>>> this is why I digged into and found that rtp send-receive command
> >>>>> and
> >>>>> its exactly what happens: voip can speak and is heard on pstn, but
> >>>>> not
> >>>>> vice versa.
> >>>>>
> >>>>> any ideas?
> >>>>>
> >>>>> Brgds
> >>>>> Gerd
> >>>>>
> >>>>> Am 29.04.2005 um 15:47 schrieb Kevin Thorngren:
> >>>>>
> >>>>>> Hi Gerd,
> >>>>>>
> >>>>>> Typically one way voice issues are due to IP Routing issues. Can
> >>>>>> the
> >>>>>> 5300 ping the SIP Phone?
> >>>>>>
> >>>>>> This URL should help you diagnose the problem.
> >>>>>> http://www.cisco.com/en/US/tech/tk652/tk698/
> >>>>>> technologies_tech_note09186a008009484b.shtml
> >>>>>>
> >>>>>> Kevin
> >>>>>> On Apr 29, 2005, at 6:49 AM, Gerd Feiner wrote:
> >>>>>>
> >>>>>>> Hi there,
> >>>>>>>
> >>>>>>> we have an AS5350 and using as a SIP-Gateway to the PSTN. Now,
> >>>>>>> there
> >>>>>>> is an intriguing issue: SIP -> PSTN voice is audible, and there
> >>>>>>> is
> >>>>>>> an RTP stream from the SIP-device - SIPURA - to the mediagateway.
> >>>>>>> But there is no stream in the SIP direction coming from the
> >>>>>>> AS5350.
> >>>>>>> I already found the
> >>>>>>>
> >>>>>>> voice rtp send-receive
> >>>>>>>
> >>>>>>> command - but it didn't do the trick. As of now, I wasn't able to
> >>>>>>> ascertain the source of the problem. It doesn't matter who is
> >>>>>>> initiating the call, it's always the same effect.
> >>>>>>>
> >>>>>>> Don't know which part of our config you need, but here are a few:
> >>>>>>>
> >>>>>>> voice rtp send-recv
> >>>>>>> !
> >>>>>>> voice service pots
> >>>>>>> fax protocol pass-through g711alaw
> >>>>>>> !
> >>>>>>> voice service voip
> >>>>>>> signaling forward rawmsg
> >>>>>>> fax protocol pass-through g711alaw
> >>>>>>> sip
> >>>>>>> rel1xx disable
> >>>>>>> no call service stop
> >>>>>>> !
> >>>>>>> ...
> >>>>>>> !
> >>>>>>> interface Serial3/0:15
> >>>>>>> no ip address
> >>>>>>> isdn switch-type primary-net5
> >>>>>>> isdn incoming-voice modem
> >>>>>>> isdn sending-complete
> >>>>>>> no cdp enable
> >>>>>>> !
> >>>>>>> voice-port 3/0:D
> >>>>>>> bearer-cap Speech
> >>>>>>> !
> >>>>>>> dial-peer voice 1 pots
> >>>>>>> tone ringback alert-no-PI
> >>>>>>> application session
> >>>>>>> incoming called-number 143677..
> >>>>>>> destination-pattern .
> >>>>>>> translate-outgoing calling 20
> >>>>>>> translate-outgoing called 20
> >>>>>>> supplementary-service pass-through
> >>>>>>> no digit-strip
> >>>>>>> direct-inward-dial
> >>>>>>> port 3/0:D
> >>>>>>> !
> >>>>>>> dial-peer voice 2 voip
> >>>>>>> tone ringback alert-no-PI
> >>>>>>> application session
> >>>>>>> incoming called-number .
> >>>>>>> destination-pattern 143677..
> >>>>>>> voice-class codec 10
> >>>>>>> session protocol sipv2
> >>>>>>> session target ipv4:x.x.x.x
> >>>>>>> supplementary-service pass-through
> >>>>>>> !
> >>>>>>> !
> >>>>>>> dial-peer search type voice data
> >>>>>>> sip-ua
> >>>>>>> nat symmetric check-media-src
> >>>>>>> sip-server ipv4:x.x.x.x
> >>>>>>>
> >>>>>>> this isn't by far complete, but it seems to be the important
> >>>>>>> part as
> >>>>>>> I figured. In addition, I don't really understand all of the
> >>>>>>> commands set, most of it was from an example, part is from the
> >>>>>>> ?-help
> >>>>>>> system and another part is from cisco's voice config guide ...
> >>>>>>>
> >>>>>>> Glad if someone could help.
> >>>>>>>
> >>>>>>> Brgds,
> >>>>>>> Gerd Feiner
> >>>>>>> _______________________________________________
> >>>>>>> cisco-voip mailing list
> >>>>>>> cisco-voip at puck.nether.net
> >>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>>> _______________________________________________
> >>>>> cisco-voip mailing list
> >>>>> cisco-voip at puck.nether.net
> >>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>>
> >>>>
> >>
> >>
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> 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