RE: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
Mark S wrote: > > For those of you trying to email me from the link in the > message, here is the updated post. Hopefully people wouldn't mail you offlist! If they trust what they are saying, why don't they share it with ALL of us? :-) That's what the list is all about. Are you saying that instead of hearing the voice conversation, you hear silence for the first 10-15 seconds? That almost sounds like a software bug or even a hardware problem. I can't see anything in your config that would cause this, though maybe somebody else will. Even if you have busied out the WAN as you say, it's supposed to handle this correctly. If it was just a second or two of silence, I would say tune your Voice Activity Detection (VAD), but 10-15 seconds, that's really bizarre. Anyone else have some ideas? ___ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com > Sorry about the duplicate. > > *** > Well, this should give you enough to chew on since voice is > becoming a hot topic. I am trying to configure VoIP with QoS. > Why over IP and not over ATM, you say? I have to controll the > call with a H.323 Gatekeeper, and that is IP. > > My problem appears to be that the call setup (or maybe > signalling?) appears to be delayed. The test results are as > follows: > > If the WAN link is saturated with data packets PRIOR to > establishing the voice call, the first 10 to 15 (approximately) > seconds of the call are lost. After the call is established, > voice is rock solid and no voice packets are delayed or lost. > > If the voice call is established PRIOR to saturating the WAN > link with data packets, the voice call is rock solid and no > voice packets are delayed or lost. > > Thoughts or configs would be appreciated. > > --Mark > > > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname Router > ! > logging buffered 4096 debugging > ! > memory-size iomem 25 > ip subnet-zero > ! > no ip domain lookup > ! > ip cef > ! > voice call carrier capacity active > voice rtp send-recv > ! > no voice hpi capture buffer > no voice hpi capture destination > ! > vc-class atm vip > vbr-rt 256 256 10 > precedence 5 > no bump traffic > no protect vc > no protect group > ! > vc-class atm normal > vbr-nrt 192 192 > precedence other > no protect vc > no protect group > ! > interface ATM0/0 > ip address 1.1.1.254 255.255.255.0 > ip nat outside > no atm ilmi-keepalive > bundle-enable > bundle qosmap > protocol ip 1.1.1.1 > encapsulation aal5snap > pvc-bundle data 0/37 > class-vc normal > pvc-bundle voice 0/36 > class-vc vip > ! > dsl equipment-type CPE > dsl operating-mode GSHDSL symmetric annex A > dsl linerate AUTO > h323-gateway voip interface > h323-gateway voip id Gatekeeper ipaddr x.x.x.x 1718 > h323-gateway voip h323-id Gateway > ip rsvp bandwidth 64 64 > ip rsvp resource-provider wfq pvc > ! > interface FastEthernet0/0 > ip address 10.200.100.1 255.255.255.0 > ip nat inside > speed auto > ! > ip nat inside source list 1 interface ATM0/0 overload > ip classless > ip route 0.0.0.0 0.0.0.0 1.1.1.1 > no ip http server > ip pim bidir-enable > ! > access-list 1 permit 10.200.100.0 0.0.0.255 > ! > call rsvp-sync > ! > voice-port 2/0 > station-id name StaID > station-id number 111222 > caller-id enable > ! > voice-port 2/1 > station-id name StaID > station-id number 111222 > caller-id enable > ! > dial-peer cor custom > ! > dial-peer voice 1 voip > destination-pattern T > session target ras > ! > gateway > ! > line con 0 > line aux 0 > line vty 0 4 > login > ! > no scheduler allocate > end Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57127&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
That is correct--I hear silence when the data pvc is saturated. However, further tests performed just recently indicate that the amount of data saturating the link corresponds to the amount of lost voice packets. That is why I thought this was a QoS issue. It almost appears that some of the call control packets are going down the data pvc instead of the voice pvc. But I don't want to comit to such a statement for fear of biasing other opinions in the newsgroup, as others may have the "real" cause to the problem already figured out. I did explore an access-list config to match on port 1720 and there were some hits, but again are there other voice payload and/or voice signaling packets traversing the data pvc? I don't know. --Mark Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57133&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
Mark, It sounds like the voice traffic is being prioritized correctly since the voice is "rock solid" after the connection is made. Looking at your config this is strange as the default IP Precedence should be 0 for voice traffic and I do not see where you have specified this in your dial peer. Based on your explanation I would expect to see something like: dial-peer voice 1 voip destination-pattern . session target ... ip qos dscp cs5 media -or- dial-peer voice 1 voip destination-pattern . session target ... ip precedence 5 With the classification statements missing from your configuration, I would expect voice to be choppy and unintelligible. The default classification for router-originated voice traffic is supposed to be ip precedence of 0 (DSCP=00). Perhaps Cisco has changed this in the latest IOS releases? You should also have "ip qos dscp cs5 signaling" present in your dial-peer configuration to identify the signalling traffic as having IP precedence=5 so that it is classified correctly and sent down your voice PVC. As it stands now, your signalling traffic should be using your data PVC. You can find some decent QoS configuration examples on Cisco's web site relating to LLQ which might also help along these lines. Cisco usually recommends setting signaling to af31 and media to ef (to make sure that if signaling and media contend for bandwidth voice quality is not affected). Since your configuration is already classifying explicitly on ip precedence=5, it might just be simpler to set the ip precedence of both media and signaling traffic to 5. I hope this helps. :) - Tom Mark S wrote: > For those of you trying to email me from the link in the message, here is > the updated post. Sorry about the duplicate. > > *** > Well, this should give you enough to chew on since voice is becoming a hot > topic. I am trying to configure VoIP with QoS. Why over IP and not over ATM, > you say? I have to controll the call with a H.323 Gatekeeper, and that is IP. > > My problem appears to be that the call setup (or maybe signalling?) appears > to be delayed. The test results are as follows: > > If the WAN link is saturated with data packets PRIOR to establishing the > voice call, the first 10 to 15 (approximately) seconds of the call are lost. > After the call is established, voice is rock solid and no voice packets are > delayed or lost. > > If the voice call is established PRIOR to saturating the WAN link with data > packets, the voice call is rock solid and no voice packets are delayed or > lost. > > Thoughts or configs would be appreciated. > > --Mark > > > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname Router > ! > logging buffered 4096 debugging > ! > memory-size iomem 25 > ip subnet-zero > ! > no ip domain lookup > ! > ip cef > ! > voice call carrier capacity active > voice rtp send-recv > ! > no voice hpi capture buffer > no voice hpi capture destination > ! > vc-class atm vip > vbr-rt 256 256 10 > precedence 5 > no bump traffic > no protect vc > no protect group > ! > vc-class atm normal > vbr-nrt 192 192 > precedence other > no protect vc > no protect group > ! > interface ATM0/0 > ip address 1.1.1.254 255.255.255.0 > ip nat outside > no atm ilmi-keepalive > bundle-enable > bundle qosmap > protocol ip 1.1.1.1 > encapsulation aal5snap > pvc-bundle data 0/37 > class-vc normal > pvc-bundle voice 0/36 > class-vc vip > ! > dsl equipment-type CPE > dsl operating-mode GSHDSL symmetric annex A > dsl linerate AUTO > h323-gateway voip interface > h323-gateway voip id Gatekeeper ipaddr x.x.x.x 1718 > h323-gateway voip h323-id Gateway > ip rsvp bandwidth 64 64 > ip rsvp resource-provider wfq pvc > ! > interface FastEthernet0/0 > ip address 10.200.100.1 255.255.255.0 > ip nat inside > speed auto > ! > ip nat inside source list 1 interface ATM0/0 overload > ip classless > ip route 0.0.0.0 0.0.0.0 1.1.1.1 > no ip http server > ip pim bidir-enable > ! > access-list 1 permit 10.200.100.0 0.0.0.255 > ! > call rsvp-sync > ! > voice-port 2/0 > station-id name StaID > station-id number 111222 > caller-id enable > ! > voice-port 2/1 > station-id name StaID > station-id number 111222 > caller-id enable > ! > dial-peer cor custom > ! > dial-peer voice 1 voip > destination-pattern T > session target ras > ! > gateway > ! > line con 0 > line aux 0 > line vty 0 4 > login > ! > no scheduler allocate > end Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57139&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
Yeah, sorry about that. I added the following: ip qos dscp cs5 media ip qos dscp cs5 signaling to my dial-peer after the original post. Unfortunately, same result. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57141&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
Related to the topic, but maybe not to your question. How do you manage the call accounting from the gatekeeper? As far as I know the gatekeeper calculates the AcctSessionTime from the time beetwenn the LCF (Location Confirm) and the Call Disengage Request. Well this results that the call duration logged from the gatekeeper would be longer that the call duration logged from the gateways.(it will include the call setup time as well). I have faced this problem once but didn't find the solution. Thanks, Hamid > That is correct--I hear silence when the data pvc is saturated. > However, further tests performed just recently indicate that the amount > of data saturating the link corresponds to the amount of lost voice > packets. > > That is why I thought this was a QoS issue. It almost appears that > some of the call control packets are going down the data pvc instead of > the voice pvc. But I don't want to comit to such a statement for fear > of biasing other opinions in the newsgroup, as others may have the > "real" cause to the problem already figured out. > > I did explore an access-list config to match on port 1720 and there > were some hits, but again are there other voice payload and/or voice > signaling packets traversing the data pvc? I don't know. > > --Mark > Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57142&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
Hamid, Well there are two different ways that you can look at this. From the telco side one may conclude that the entire duration of the call is the actual cost of the call, including call setup. From the customer side, the majority of customers would argue that call setup should not be billed, as that is not part of the actual voice conversation. However, ultimately, all costs are eventually passed to the consumer. Unfortunately, this doesn't directly answer your question but does explain the two theories. I don't get into call accounting too much. --Mark Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57144&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VoIP+QoS+xDSL+H.323Gatekeeper [7:57121]
To paint you a better picture here is the scenerio...I am calling a number that I know will respond initially with a voice annoincement (ie. Voice mail system). When data is not flooding the wan link the call is fine. I get the entire announcement beginning with "Thank you for calling xyz company, the nations leading provider of..." When data IS flooding the wan link, the call eventually goes through but I hear the recording starting in the middle of the stream... "leading provider of..." In the second case, why wouldn't I hear the entire message, just delayed until the call set-up packets traversed the network? ""Mark S"" wrote in message news:200211081804.SAA07463@;groupstudy.com... For those of you trying to email me from the link in the message, here is the updated post. Sorry about the duplicate. *** Well, this should give you enough to chew on since voice is becoming a hot topic. I am trying to configure VoIP with QoS. Why over IP and not over ATM, you say? I have to controll the call with a H.323 Gatekeeper, and that is IP. My problem appears to be that the call setup (or maybe signalling?) appears to be delayed. The test results are as follows: If the WAN link is saturated with data packets PRIOR to establishing the voice call, the first 10 to 15 (approximately) seconds of the call are lost. After the call is established, voice is rock solid and no voice packets are delayed or lost. If the voice call is established PRIOR to saturating the WAN link with data packets, the voice call is rock solid and no voice packets are delayed or lost. Thoughts or configs would be appreciated. --Mark version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Router ! logging buffered 4096 debugging ! memory-size iomem 25 ip subnet-zero ! no ip domain lookup ! ip cef ! voice call carrier capacity active voice rtp send-recv ! no voice hpi capture buffer no voice hpi capture destination ! vc-class atm vip vbr-rt 256 256 10 precedence 5 no bump traffic no protect vc no protect group ! vc-class atm normal vbr-nrt 192 192 precedence other no protect vc no protect group ! interface ATM0/0 ip address 1.1.1.254 255.255.255.0 ip nat outside no atm ilmi-keepalive bundle-enable bundle qosmap protocol ip 1.1.1.1 encapsulation aal5snap pvc-bundle data 0/37 class-vc normal pvc-bundle voice 0/36 class-vc vip ! dsl equipment-type CPE dsl operating-mode GSHDSL symmetric annex A dsl linerate AUTO h323-gateway voip interface h323-gateway voip id Gatekeeper ipaddr x.x.x.x 1718 h323-gateway voip h323-id Gateway ip rsvp bandwidth 64 64 ip rsvp resource-provider wfq pvc ! interface FastEthernet0/0 ip address 10.200.100.1 255.255.255.0 ip nat inside speed auto ! ip nat inside source list 1 interface ATM0/0 overload ip classless ip route 0.0.0.0 0.0.0.0 1.1.1.1 no ip http server ip pim bidir-enable ! access-list 1 permit 10.200.100.0 0.0.0.255 ! call rsvp-sync ! voice-port 2/0 station-id name StaID station-id number 111222 caller-id enable ! voice-port 2/1 station-id name StaID station-id number 111222 caller-id enable ! dial-peer cor custom ! dial-peer voice 1 voip destination-pattern T session target ras ! gateway ! line con 0 line aux 0 line vty 0 4 login ! no scheduler allocate end Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57351&t=57121 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
