<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
<DIV>it you configure CCM extension mob. as autologout, yes when you login to 2nd phone the first phone will go autlogout.and the first phone will back to its normal directory number.</DIV><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: "cisco-voip-request@puck.nether.net" <cisco-voip-request@puck.nether.net><BR>To: cisco-voip@puck.nether.net<BR>Sent: Friday, November 10, 2006 11:43:30 PM<BR>Subject: cisco-voip Digest, Vol 45, Issue 61<BR><BR>
<DIV>Send cisco-voip mailing list submissions to<BR> cisco-voip@puck.nether.net<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>or, via email, send a message with subject or body 'help' to<BR> cisco-voip-request@puck.nether.net<BR><BR>You can reach the person managing the list at<BR> cisco-voip-owner@puck.nether.net<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of cisco-voip digest..."<BR><BR><BR>Today's Topics:<BR><BR> 1. Re: Optimizing RTP on the WAN. (Joe Pollere (US))<BR> 2. Re: auto QoS for Ip telephony solution (Ed Leatherman)<BR> 3. Extension Mobility (Cleaveland, AJ Allan @
IS)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Fri, 10 Nov 2006 16:13:35 -0500<BR>From: "Joe Pollere \(US\)" <Joe.Pollere@us.didata.com><BR>Subject: Re: [cisco-voip] Optimizing RTP on the WAN.<BR>To: "Joe Pollere \(US\)" <Joe.Pollere@us.didata.com>, "Scott ODonnell"<BR> <scott.odonnell@gmail.com>, <cisco-voip@puck.nether.net><BR>Message-ID:<BR> <C65033A817B5734392E55CB9DF44610403D8A23B@USNAEXCH.na.didata.local><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Sorry that should read "will be exaggerated beause of the larger payload size."<BR><BR>________________________________<BR><BR>From: cisco-voip-bounces@puck.nether.net on behalf of Joe Pollere (US)<BR>Sent: Fri 11/10/2006 4:07 PM<BR>To: Scott ODonnell; cisco-voip@puck.nether.net<BR>Subject: Re: [cisco-voip] Optimizing RTP on the WAN.<BR><BR><BR>You
could change the default sampling rate from 20 ms to 30 ms but the bandwidth savings is really not that significant. However If you are experiencing any dropped packets it will be exasperated beause of the larger payload size. <BR><BR>See this for reference:<BR><BR><A href="http://www.informit.com/articles/article.asp?p=357102&seqNum=1&rl=1" target=_blank>http://www.informit.com/articles/article.asp?p=357102&seqNum=1&rl=1</A><BR><BR><snip><BR><BR>Table 2-1 details the bandwidth per VoIP flow (both G.711 and G.729) at a default packetization rate of 50 packets per second (pps) and at a custom packetization rate of 33 pps. This does not include Layer 2 overhead and does not take into account any possible compression schemes, such as Compressed Real-Time Transport Protocol (cRTP, discussed in detail in Chapter 7, "Link-Specific Tools"). <BR><BR>For example, assume a G.711 VoIP codec at the default packetization rate (50 pps). A new VoIP packet is
generated every 20 ms (1 second / 50 pps). The payload of each VoIP packet is 160 bytes; with the IP, UDP, and RTP headers (20 + 8 + 12 bytes, respectively) included, this packet become 200 bytes in length. Converting bits to bytes requires multiplying by 8 and yields 1600 bps per packet. When multiplied by the total number of packets per second (50 pps), this arrives at the Layer 3 bandwidth requirement for uncompressed G.711 VoIP: 80 kbps. This example calculation corresponds to the first row of Table 2-1.<BR><BR><BR>Table 2-1 Voice Bandwidth (Without Layer 2 Overhead)<BR><BR>Bandwidth Consumption<BR><BR>Packetization Interval<BR><BR>Voice Payload in Bytes <BR><BR>Packets Per Second<BR><BR>Bandwidth Per Conversation<BR><BR>G.711<BR><BR>20 ms<BR><BR>160<BR><BR>50<BR><BR>80 kbps<BR><BR>G.711<BR><BR>30 ms<BR><BR>240<BR><BR>33<BR><BR>74 kbps<BR><BR>G.729A<BR><BR>20 ms<BR><BR>20<BR><BR>50<BR><BR>24 kbps<BR><BR>G.729A<BR><BR>30 ms<BR><BR>30<BR><BR>33<BR><BR>19
kbps<BR><BR><BR><BR>NOTE<BR><BR>The Service Parameters menu in Cisco CallManager Administration can be used to adjust the packet rate. It is possible to configure the sampling rate above 30 ms, but this usually results in poor voice quality.<BR><BR><snip><BR><BR><BR><BR>HTH's <BR><BR>Joe<BR><BR>________________________________<BR><BR>From: cisco-voip-bounces@puck.nether.net on behalf of Scott ODonnell<BR>Sent: Fri 11/10/2006 3:55 PM<BR>To: cisco-voip@puck.nether.net<BR>Subject: [cisco-voip] Optimizing RTP on the WAN.<BR><BR><BR>I have a customer that is getting clobbered high WAN utilitization due to RTP streams.<BR>While I recognize that at some point you just need more bandwidth are there any other ways to reduce the bandwidth RTP requires beyond codec selection and CRTP?<BR><BR>I vaguely remember back in the old "toll bypass" days, you could adjust the number of samples per packet or the sample rate and it could make a real difference in the bandwidth.<BR><BR>Any
knobs like that in CallManager?<BR><BR>Scott<BR><BR><BR>________________________________<BR><BR>Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. <BR><BR><BR><BR><BR>-----------------------------------------<BR>Disclaimer:<BR><BR>This e-mail communication and any attachments may contain<BR>confidential and privileged information and is for use by the<BR>designated addressee(s) named above only. If you are not the<BR>intended addressee, you are hereby notified that you have
received<BR>this communication in error and that any use or reproduction of<BR>this email or its contents is strictly prohibited and may be<BR>unlawful. If you have received this communication in error, please<BR>notify us immediately by replying to this message and deleting it<BR>from your computer. Thank you.<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20061110/ce6d8023/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20061110/ce6d8023/attachment-0001.html</A> <BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Fri, 10 Nov 2006 16:40:43 -0500<BR>From: "Ed Leatherman" <ealeatherman@gmail.com><BR>Subject: Re: [cisco-voip] auto QoS for Ip telephony solution<BR>To: "Erik Erasmus (E)" <ErasmuE4@telkom.co.za><BR>Cc:
cisco-voip@puck.nether.net<BR>Message-ID:<BR> <94a1afde0611101340r7729ed9ewf42f2e4f874b1118@mail.gmail.com><BR>Content-Type: text/plain; charset="utf-8"<BR><BR>Revisiting this thread since it seemed most related to my question.<BR><BR>As below, i've mainly been using "auto qos voip trust" on our interfaces<BR>between cat 3750 switches. I've been going through the qos documentation,<BR>particularly the SRND for enterprise qos - basically what it seems to be is<BR>there are alot of differences between running "auto qos" and the recommended<BR>configuration that they provide in the srnd.<BR><BR>One particular thing that just jumped out at me today was, using auto qos<BR>voip trust on an interface doesn't appear to enable the priority queue<BR>(according to the "sh mls qos int queueing" command). If that's true i've<BR>got a ton of switches out there that need their configs fixed.. All my<BR>traffic comes out marked OK, and queueing and so forth
are setup OK on our<BR>core routers but 90% of our distribution and access layer switches are 3550<BR>or 3750 models.<BR><BR>So is auto-qos flat out not intended for anything but trusted endpoints such<BR>as ccm servers? the further I dig into this the more it seems like this is<BR>the case.<BR><BR><BR>On 9/18/06, Erik Erasmus (E) <ErasmuE4@telkom.co.za> wrote:<BR>><BR>> Thanks Ed<BR>><BR>> I think it sound like good advice - I was basically planning to try it<BR>> like you say.<BR>> If one does not have extensive resources it is a lot easier and possibly<BR>> good enough in most cases to use auto QoS.<BR>><BR>> thanks for your advice - will let the group know if during my<BR>> implementation I see something interseting.<BR>><BR>> ------------------------------<BR>> *From:* Ed Leatherman [mailto:ealeatherman@gmail.com]<BR>> *Sent:* Mon 2006-09-18 16:29<BR>> *To:* Erik Erasmus (E)<BR>> *Cc:*
cisco-voip@puck.nether.net<BR>> *Subject:* Re: [cisco-voip] auto QoS for Ip telephony solution<BR>><BR>> Hi Erik,<BR>><BR>> I'm no qos expert by any stretch, this is just what we do and it seems to<BR>> work out for us.. traffic markings come out end-to-end how we want them to<BR>> at least. If someone else sees something wrong with it i'd love to hear it.<BR>><BR>> I've been using "auto qos voip trust" on both those instances, i've been<BR>> adding to that "mls qos trust dscp" to the callmanager ports and layer 3<BR>> links, because the auto trust statement seems to put mls qos trust cos<BR>> instead. To my understanding the callmanager servers mark their traffic with<BR>> the dscp bits.<BR>><BR>> Ed<BR>><BR>> On 9/18/06, Erik Erasmus (E) <ErasmuE4@telkom.co.za> wrote:<BR>> ><BR>> ><BR>> > Currently at branches we use auto-QoS VoIP cisco-phone on all the 3560<BR>> > series switchports
connection to cisco phones and the same at HQ on the 4500<BR>> > series switches.<BR>> ><BR>> ><BR>> ><BR>> > 1. I want to know what is recommended for the trunk interface on<BR>> > the switch between the branch gateway and the lan switch on the<BR>> > 802.1Q trunk and also on the router main / subinterfaces.<BR>> > 2. Also what is recommended on switch ports connecting to the<BR>> > Cisco Call Manager at HQ. Is it auto QoS VoIP trust ???<BR>> ><BR>> ><BR>> Ed Leatherman<BR>Senior Voice Engineer<BR>West Virginia University<BR>Telecommunications and Network Operations<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20061110/146e5a05/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20061110/146e5a05/attachment-0001.html</A> <BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Fri, 10 Nov 2006 15:08:45 -0600<BR>From: "Cleaveland, AJ Allan @ IS" <Allan.J.Cleaveland@L-3Com.com><BR>Subject: [cisco-voip] Extension Mobility<BR>To: <cisco-voip@puck.nether.net><BR>Message-ID:<BR> <7AA7308B49C9A648929E81CD96CF18BC2A6D99@gvlexch01.is.l-3com.com><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>A couple questions about Extension Mobility. I haven't used it before<BR>but it's being looked at.<BR><BR>1) If I log into a phone go to another room and log into another phone<BR>with this feature am I automatically logged out of the first phone?<BR><BR>2) Can I handle the logging in programmatically? Such as through an<BR>API, adjust who's logged in to what and so forth?<BR><BR>Thank
you,<BR>Allan<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20061110/4dad92ee/attachment.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20061110/4dad92ee/attachment.html</A> <BR><BR>------------------------------<BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR>cisco-voip@puck.nether.net<BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>End of cisco-voip Digest, Vol 45, Issue 61<BR>******************************************</DIV></DIV><BR></DIV></div><br></body></html>