[cisco-voip] RTP only one way?
Gerd Feiner
g.feiner at cablesurf.de
Fri May 6 09:39:18 EDT 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
Url : https://puck.nether.net/pipermail/cisco-voip/attachments/20050506/531e48a2/PGP.bin
More information about the cisco-voip
mailing list