SwAN DiVE 別館実験室

CISCO/CCIE Voice/Voice 基礎/メディアリソース

2014-02-16T13:15:47+09:00

&topicpath() #ls() *メディアリソースの概要 -ハードウェアとソフトウェアがある -CUCMが初期化されると、メディアリソースマネージャが作成される。 -メディアリソースの種類 --Teleconference (会議) --Transcoding (トランスコード) --MTP (メディアターミネーションポイント) --Music on Hold (保留音) --Announciator (アナンシエータ) --TRP (Trunsted Relay Point) -MRGとMRGLを使用して、複数のCUCM間でリソースを共有する。使わない場合は、1つのCUCMからしか使用不可。 -リソースごとにMRGを作成し、MRGLを使って割り当てする優先順位を決める。 -同じ優先順位の場合は、ロードバランス。 -IOSベースのメディアリソースのフェイルオーバ機能にはグレースフルとイメディエートがある。 -グレースフルの場合は、全てのメディアアクティビティが停止してからバックアップに切り替える。 -イメディエートの場合は、プライマリでエラーがあるとすぐにバックアップに切り替える。 *メディアリソースマネージャ -CUCMにはメディアリソースマネージャというメディアリソースの割り当てが必要かどうか判断するソフトウェア。 -メディアリソースはDSPかUnified CM IP Voice Media Streaming Application で提供される。 -MRGLとMRGは割り当てのためにグループ化する概念 -メディアリソースマネージャは下記のメディアリソースタイプを管理する --Music On Hold (MoH) --ユニキャスト Conference Bridge (CFB) --ソフトウェアMTP (メディア・ターミネーション・ポイント) --トランスコーダ (XCODE) --MTP *UCM IP Voice Media Streaming Application -アクティブにすると下記のリソースが１つづつ自動的に作成される -不用な場合は、パラメータを変更して無効にできる。 --会議ブリッジ --保留音(MoH) --アナンシエータ --MTP -メディアリソースを頻繁に利用する場合は、リソース専用のサーバを配置内のノードにたてることを推奨 *DSP -High Complexity モード、Medium Complexityモードもしくは Flexモードがある -High/Medium Complexity Mode --着信コールのコーデックのcomplexity が同じかそれ以上い設定されているリソースが必要 --Medium Complexity でHigh Complexityの着信コール処理はできないが、その逆は可能 -Flexモード --C5510チップセットを使用するHWプラットフォーム上か、PVDM3が必要 --設定時にComplexity を設定する必要がない --C5510のDSPコールのたびにMIPS(Millions of Instruction per seconds)単位を差し引く。リソースがある限りコールを受け付ける --PVDM3も同様にクレジットベース。各モジュールに個定数のクレジットを割り当て、使うたびに差し引いていく。 --オーバーサブスクリプションをサポート。リソースが枯渇すると音声障害が発生する恐れがある。 --G.711の呼処理は最大16個。Medium Complexityでも最大8個 -DSPの計算には下記の計算機を使う --http://www.cisco.com/go/dspcalculator <-現状の場合 --http://www.cisco.com/cgi-bin/Support/DSP/cisco_dsp_calc.pl　<- 12.4T以前の場合 *会議 -複数の参加者を1つのコールに参加させるリソース。 -設定されている最大数まで１つのコールに参加可能。 -参加者とメディアリソースの間は1対1の対応。 -メディアリソースから参加者への出力ストリーム、当事者以外のユーザのストリームを合成したもの。 -会議の種類はオーディオ会議、ビデオ会議、セキュア会議に分けられる。 -オーディオ会議 --ソフトウェアとハードウェアがある --一部のハードウェアはG.729,G.723など複数のLow-Bit Rateストリームをサポート、混合モードもサポートする場合もある。 --ソフトェアオーディオ会議（Cisco IP Voice Media Streaming Application） ---G.711とWidebandをミックスできる ---設定できる会議数はサーバで有効になっているアプリケーションにより異なる。 --ハードウェアオーディオ会議(NM-HDV,PVDM) ---参加人数は8,16,32と設定可。最大32人 ---WS-SVC-CMM-ACT (6k/7600用のモジュール）複数のDSPで用途の異なるメディアリソースに利用可。ブリッジごとに128人まで。 ---PVDM2ベースのハードウェアは単一のシャーシで同時に音声インターフェイスを利用可。他のメディアリソース機能は不可。 -ビデオ会議 --Voice-Activated（話者切り替え）/ Continuous-Presence（分割表示） --ソフトウェアとハードウェアがある --ソフトウェアビデオ会議 ---Cisco Unified MeetingPlace Express メディアサーバはアドホックテレビ会議をサポート ---Voice-Activated (話者切り替え）のみ --ハードウェアビデオ会議 ---Cisco 3500 (MCU) ---15.1(4)M以降はPVDM3 DSPでサポート。オーディオ会議用にも使用可。 -セキュア会議 --デバイス、会議リソースを認証。 --会議メディアの暗号化 --最も非セキュアな参加者の設定に合わせる。 --ビデオ会議のサポートはなし。 --IOSベースのDSPは一つで8人までサポート。 --シグナリングの一部はIPSecに依存する可能性あり。 --CUCMとCME間のカスケードは不可。 --MTPとTranscodeはサポートしない。MTP/Transcodeを使って呼び出された場合は非セキュア。 *トランスコーディング -１つのコーデックを別のコーデックに変換する。 -MTPと同じ機能も提供できる。両方必要な場合はトランスコーダが選択される -トランスコーディングにはDSPが必要 -PVDP2-16で、low-to-Mediumは8、low-to-highは6セッションをサポート -PVDM3-16で、low-to-mediumは12,low-to-highは10セッションをサポート *MTP (メディア・ターミネーション・ポイント) -2つの音声ストリームをブリッジし、各々のストリームをセットアップ・終了する。 -G.711ulawからalawにトランスコード・サンプルサイズの異なる２つの接続をブリッジ。再パケット化するにはDSPが必要 -DTMFが異なる場合はMTPを間に動的に入れて変換するが、スケーラビリティがない。 -リソースが足りない場合は、設定で [Fail call if MTP allocation fails] がある。 -[[DTMFはこちらを参照>http://www54.atwiki.jp/latte05/pages/30.html#id_92cb999f]] --SIP 以外の2つのエンドポイント間のコールには、MTP は必要ない --2つのSIPエンドポイント間もMTPは必要ない --SIPエンドポイントとSIP以外のエンドポイントの場合はMTPが必要になることもある。 -会議の参加者のデバイスの中に RFC 2833がある場合はMTPが必要 *MTPリソース -ソフトウェアとハードウェア -ソフトウェア(CUCM)はCisco IP Voice Media Streaming Applicationを有効にすることで使われる。G711のみサポート。 -ソフトウェア(IOS)はG.711 mu-law および a-law、G.729a、G.729、G.729ab、G.729b、パススルーをサポート。同時に設定できるコーデックは一つのみ。 *TRP(信頼されたリレーポイント) -メディアストリームに挿入してコントロール、処理を追加するデバイス。 -使用するためには、CUCM上でTRPを設定することと、TRPのアンカーポイントとして実際に動作するデバイス -TRPはMTPをアンカーポイントとすることができる。 *アナンシエータ -Cisco IP Voice Media Streaming Applicationのソフトウェア機能で音声トーンやプログレストーンをユーザに流す -SIPデバイスの場合は、必要に応じてCUCMからSIP電話機に呼び出せるように、登録時にデバイスに（プッシュ）ダウンロードされる。 -G.711 a-law、mu-law、G.729、Wideband コーデックをトランスコーダを用いずにサポート -次の機能はアナンシエータリソースが必要 --Cisco Multilevel Precedence Preemption（MLPP） --SIP トランクを介した統合 --Cisco IOS ゲートウェイとクラスタ間トランク --システムメッセージ --会議 -Cisco IP Voice Media Streaming Application をアクティブにすると自動的にアナンシエータが作られる -アナンシエータはメディアデバイスとしてみなされるため、MRG(メディアリソースグループ）として、使用するアナンシエータを制御できる -デフォルトでは48の同時ストリーム．10Mbps以下は24に設定を推奨 -スタンドアローンサーバ（ＣＵＣＭが動いてない）では255の同時ストリーム。 *MoH (保留音) -Cisco IP Voice Media Streaming Applicationを有効にすること。 -動作するには、各MoHサーバがクラスタに含まれ、データレプリケーションスキーマに参加していること。 -データレプリケーションスキーマを通じて次の情報を共有する必要がある。 --オーディオソースの数とID。最大51個 --マルチキャスト or ユニキャストのトランスポートの種類 --マルチキャストアドレス（ストリーミング用のIPアドレス） -ユニキャストの保留音の場合は、接続ごとに別々のストリームを使うため帯域を消費する -マルチキャストの保留音の場合は、リソースと帯域幅を節約できるが、ネットワークがマルチキャストに対応してない場合や、デバイスがマルチキャストに対応していない場合が多い -CUCMクラスタごとに51個のオーディオソースを指定できる。1個のみ固定ソース。50個はオーディオファイルにできる。 -CUCMはG711（a-law および mu-law）、G.729 Annex A、およびワイドバンドコーデックのMoHをサポート -オーディオファイルはwav形式 -共存（Shared)、またはスタンドアロン MoHサーバを用意する。 -1つのOVAで最大1,000MoHストリーム (ユニキャスト＋マルチキャスト） - Maximum Half Duplex Streamsはユニキャスト - Maximum Multicast Connections はマルチキャスト。最大数は 204 - 保留率で計算する。30,000台で保有率が2%であれば、ユニキャストであれば、600MoHストリームが必要。 -CodecをG.729は音声通話用に最適化されているため、音楽用としては最低限の音質。 -クラスタ内でユニキャストとマルチキャストの両方をサポートする場合の留意点 --別々にMoHサーバを配置。一つはユニキャストを無効。もう一つはマルチキャストを無効 --2つのMRGをもつ1台のサーバ。両方必要な場合はマルチキャストに設定。 -MoHの選択プロセス --保留側（保留を押すほう）と被保留側（保留されたほう）がある --保留側のオーディオソースによって決まる。 --被保留側のMRGLがオーディオソースを指定する。 --被保留側に設定されたMRGLからストリームを受信する。 ---- &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎/トランク

2014-02-10T14:23:26+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *トランク -トランクとはCUCMにおける通信チャンネルのこと -SIPトランク、H323トランク、クラスタ間トランク(ICT:Inter-Cluster Trunk)がある -[[SIPトランクとH.323トランクの比較>http://www.cisco.com/cisco/web/support/JP/docs/VAUC/IPTelep/UCMGR_CallMGR_/IDG/008/trunks.html?bid=0900e4b18359359a#pgfId-1044377]] *SIPトランク -各トランクで最大16 IPアドレス、FQDN、または単一のDNS SRVをサポート -9.xよりクラスタ間トランクはSIPをサポート。機能がH323トランクより豊富。 -昔のバージョンを使うとH.323 Annex M1 が推奨される -シスコ以外のアプリケーションベンダ、プロバイダーとの接続もSIPを推奨 -[Run on all Active Unified CM Nodes]をONにすると、SIPデーモンを利用してどのサブスクライバでも発信・着信が可能。以前のバージョンはノードを三つまで指定する必要があった。 -SDP(session Description Protocol)によってメディア情報をネゴシエートする。 -SDPはRFC 3261で定義されている -SDPはデバイスでサポートされるメディアストリーム、コーデック、方向属性、IP アドレス、使用されるポートなどを記述する -SDPは下記の2種類の場合がある --発信者が初期INVITEメッセージでEarly Offerをする。MTPが必要。 --着信者が信頼性のある返答にDelayed Offerで送信する。MTPは必要ない。Default -アーリーメディア (Early Media) --場合によって先行してメディアパスを確立する必要がある ---クリッピング（オーディオカットスルー遅延）を軽減させるか、着信側でネットワークのVMを提供する場合 ---DTMFまたは、IVRにアクセスさせる場合 -SIPトランクの可用性 --標準の Unified CM Group (3つまで選択) --[Run on all Active Unified CM Nodes]をON --単一のSIP トランクに複数の宛先 IP アドレス --SIP OPTIONS pingを有効にする *MTPが必要な場合は？ -SIP トランク上で SIP アーリーオファーを配信する場合（キャリアが要求する場合も） -DTMF転送の不一致に対処する場合 -RSVP エージェントとして動作する場合 -TPPとして動作する場合 -IPv4からIPv6へ変換する場合 *SIPトランクのMTP -ソフトウェア（Ｔトレイン） -ハードウェア（オンボード DSP リソースを使用） -SIPトランクのDTMFシグナリング方法を選択する。 --DTMF Signaling Method：No Preference ---MTPの利用を最小限に抑える。両方のエンドポイントがNTEをサポートする場合はMTPは必要ない。 --DTMF Signaling Method：RFC 2833 ---片方、もしくは両方NTEをサポートしてない場合、強制的にMTPを割り当てる。 --DTMF Signaling Method：OOB and RFC 2833 ---KPML（または Unsolicited NOTIFY）とNTE ベースの両方のDTMF送信 ---両方ともサポートされている場合のみMTPがアサインされない。ほとんどのケースはアサインされる。 *Early Offerの設定 -SIP Trunk上で[MTP Required]をOnにする -SIP Profile上で[Early Offer support for voice and video calls (insert MTP if needed)] をOnにする（推奨） *SIP Trunkのセキュリティ -メディア暗号化 --トランクの[SRTP allowed]をOnにする --メディアの暗号化のみ。シグナリングは暗号化されない --暗号化されている場合は電話機に鍵アイコンがでる。 --[MTP Required]をチェックしている場合はMTPがパススルーコーデックをサポートしないためRTPを暗号化できない。 --[Early Offer support for voice and video calls (insert MTP if needed)]でMTPを使用しない場合は暗号化される。 --SAF対応のSIPトランクではサポートされない -シグナリング暗号化 --SIPプロファイルでTLSを設定する。 --TLS は X.509 証明書の交換を使用して認証する。 *H.323トランク -H.225呼制御。H.245メディア制御シグナリングはTCP.GWとのRASはUDP. +クラスタ間トランク（非ゲートキーパー制御) +クラスタ間トランク（ゲートキーパー制御) +H.225 トランク（ゲートキーパー制御) -クラスタ間トランク(ゲートキーパ制御) --[Run on All Active Unified CM Nodes] 機能をサポートしない --h323_id に_n というノード番号が自動生成され変更不可。 --デフォルトでロードバランス。 --避ける場合は gw-priority の設定で優先順位をつける。 -H.225 トランク（ゲートキーパー制御） --CUCMクラスタに追加で、ゲートウェイ、会議システムなどのH.323デバイスと連動して動作 -H.323のMTP --H.323トランクは基本的にMTPは必要ないが、下記の場合は必要 ---通信相手がH.323 version1 ---H.323付加サービス。ECS (Empty Capabilility Set)でOpenLogicalChannelとCloseLogicalChannelをサポートしてない場合（ほとんどない） ---H.323 Fast Start をする場合（着信Fast ConnectはMTPを必要としないが、発信Fast Connectは必要) -DTMF 転送 --アウトオブバンド・インバウンド両方ともサポート --設定オプションはなし。必要に応じてリレー変換が必要な場合はMTPを動的にアサイン。 *H323トランクのセキュリティ -メディア暗号化 --トランクの[SRTP allowed]をOnにする -シグナリング暗号化 --暗号化はIPSec --IPSecをCUCMサーバで使うとパフォーマンスに影響があるため、インフラでIPsecにすることを推奨。 --[MTP Required]をチェックしている場合はMTPがパススルーコーデックをサポートしないためRTPを暗号化できない。 &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎/LDAP統合

2014-01-27T14:03:04+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *LDAP の同期化 -DirSyncを使用 -エンドユーザだけに適用 -アプリケーションユーザはパブリッシャーのDBを使用 -LDAPディレクトリからインポートされた情報は、CUCMから変更不可 -LDAP同期されたユーザをローカルユーザに変換した後は、ユーザ情報をLDAPから再度同期されることはない。 *LDAP 認証 -Simple_Bind 操作してIMSライブラリが社内 LDAP ディレクトリに対して LDAP 同期エンドユーザのクレデンシャルを認証 -アプリケーションユーザのパスワードはパブリッシャーのDBを使用 -Cisco エクステンションモビリティの PIN もローカル認証 &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎/RFC

2014-01-26T12:54:17+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *音声関連のRFC -RFC1889 - RTP(Realtime Transport Protocol) -RFC2327 - SDP(Session Description Protocol) -RFC2205 - RSVP(Resource Reservation Protocol) -RFC2326 - RTSP(Real Time Streaming Protocol) -RFC2974 - SAP(Session Announcement Protocol) -RFC1034など - DNS(Domain Name Ssytem) -RFC2251 - LDAP(Lightweight Directory Access Protocol) &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎/ゲートウェイ

2014-01-26T02:21:15+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *アナログゲートウェイ -E&M,FXS,FXO *デジタルゲートウェイ -PRI,BRI,T1 CAS *ゲートウェイプロトコル -H.323 -MGCP(Media Gateway Control Protocol) -SIP (Trunk) *DTMFサポート -H.323ゲートウェイ --拡張H.245 にてアウトオブバウンドでサポート dial-peer voice xx voip dtmf-relay h245-alphanumeric --preserveの設定でエラー時にも通話中の電話は切れない（冗長性） voice service voip h323 call preserve *MGCP -DTMFパッケージをCUCMからロード -MGCPを介して*シンボル*をCUCMへアウトオブバウンドで送付 mgcp dtmf-relay VOIP codec all mode out-of-band -RFC2833の場合は fm-packageを使用。12.4(6)T以降 -CUCMはメインをcall-agent で指定 -CUCMのバックアップはccm-manager redundant-host で設定。切り替え時にも通話中の電話はそのままキープされる。 -フォールバックは下記の設定. call-manager redundancy switchback [immediate|graceful|delay ] - immediate はすぐに、graceful は通話中の電話がなくなった後に、delayは設定値の時間後に。 *SIP -CUCMではDTMF Signaling Method を No Preferenceにすることを推奨 -NTE(Named Telephony Event)/RFC2833 -UN(Unsolicited SIP Notify) -KPML(Key Press Markup Language) -冗長構成で、初期設定はInviteを6回送付し、応答がない場合は優先度の高い次のdial-peerを使用。 -SIP UAでタイマー値を変更 sip-ua retry invite timers trying -高速化する場合は、monitor probe icmp-ping。pingが届かない場合はdial-peerをshutdown. NTE dial-peer voice xx voip dtmf-relay rtp-nte UN dial-peer voice xx voip dtmf-relay sip-notify KPML dial-peer voice xx voip dtmf-relay sip-kpml *FAXモデムのサポート -パススルーとリレー -パススルー --パススルーはアナログFAXをサンプリング化してG.711コーデックを使って転送される。 --パススルーにはモデムパススルーとFAXパススルーがある。 --モデムパススルー: シスコのNSE(Named Signaling Event)を用いて、コールを音声モードからパススルーモードに切り替える。 --FAXパススルー: H323、もしくはSIPの呼制御プロトコルを用いて、コールを音声からパススルーモードに切り替える。 --FAXパススルーは、G3 FAXのV.21フラグ検出をトリガとしているため、アナログやSG3 FAXには使用不可。 -リレー --パススルーより複雑 --FAX信号からアナログ搬送波を取り除き、FAX HDLCデータフレームを復元し、関連情報を取り出す --取り出したデータをパッケージ化して、相手側のゲートウェイに転送。 --相手側のゲートウェイでは、リレープロトコルからFAX情報を取り出し、FAX HDLCフレームに再構築、アナログ変調し、FAXに送信。 --シスコでは、T.38 FAXリレー(プロトコルベース・NSEベース)とCisco FAXリレー(RTPダイナミックペイロードタイプ(PT))をサポート --T.38が推奨 -エラー訂正モード（ECM）は、FAX コールで取り決められた機能でエラーを防ぐが、再送信回数とコール失敗数が増えるため、Disableにすることも検討する。 --ECMがDisableの場合はFAXのイメージ品質が悪くなる可能性がある。 -Super G3 FAX --V.34 FAXとも呼ばれ,33,6kbpsでのFAX送信をサポート --本来のスピードでサポートするにはモデムパススルーにする必要がある -CiscoではV.90でのサポートはしていない &link_back() &link_edit()

CISCO/CCIE Voice

2014-01-14T13:48:32+09:00

&topicpath() #ls() ---- **リンク -[[SRDN CUCM 9.0 System Guide (日本語)>http://www.cisco.com/cisco/web/support/JP/docs/VAUC/IPTelep/UCMGR_CallMGR_/IDG/008/uc9x.html]] -[[SAF(Service Advertisement Framework)>http://www.cisco.com/en/US/docs/ios-xml/ios/saf/configuration/15-mt/saf-15-mt-book.html]] -[[SIP設定ガイド>http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html]] ---- &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎/ビデオ

2014-01-05T06:00:50+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *エンドポイント -ビデオ対応のエンドポイント |Cisco IP Phone 9000 Series| |Cisco E20 Video Phone| |Telepresence EX60/EX90| |3rd Party Device| *リージョン -リージョンを設定する際に、&bold(){Audio Codec} と &bold(){Video Bandwidth}を指定する -Audio Codec は音声、およびビデオの音声チャンネルの最大ビットレート -G.711なら64kbpsを割り当てるとG.711、G.722、G.728、iLBCが使用可能 -Video Bandwidthは慣例に従い音声の帯域を含める。例えばG.711の場合は320kbpsではなくて,384Kbps -&bold(){[Retry Video as Audio]}を設定すると、ビデオに失敗した際は音声として処理される -リージョンの[video bandwidth]をNoneとした場合は、着信デバイスのRetry Video as Audioの設定によりコール拒否か音声通話となる *[[コールアドミッション制御>CISCO/CCIE Voice/Voice 基礎/コールアドミッション制御]] -リンク参照 -ロケーションベースのCACの場合、ロケーションで設定された帯域を上回るリクエストがあった際は拒否か音声通話にフォールバックされる *QoS -ビデオトラフィックはバースト性があるため、20%ほど上乗せしたほうが無難 *セキュリティ -SRTPの機能をver9.xで追加 -セキュア会議はhttpsでMCUに接続、TLSがシグナリング,SRTPがメディアとなる。端末でこれらのプロトコルをサポートしている場合のみ。 *マルチポイント会議 -アドホックビデオ会議 --SCCPとSIPビデオ端末は可能。H323ビデオ端末は不可。 -Meet-meビデオ会議 --SCCP端末、またはSIP端末のIP Phoneで [Conf]、[Join]、または[MeetMe]を設定した場合、メディアリソースが利用される -スケジュールされたビデオ会議 --MCUもしくはミドルウェア時間管理システムに依存 --Unified MeetingPlaceやUnified Video Canference Managerなど -機能 --Voice-Activated(話者切り替え)はMCUが声の大きさと長さを判断して切り替える。ホールドタイマーで切り替え時間の調整可能 --MCU会議コントローラがマニュアルで切り替え --順次切り替え --Continuous-presence(分割表示) *その他 -CUCMはSIPベースのため、H323との接続の場合は、ゲートキーパやVCSが必要 -CTIアプリケーション（Ciscoの ER、IP IVR、Contact Center)や3rd Party Applicationもサポート &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎/コールアドミッション制御/RSVP

2014-01-05T00:07:44+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *RSVP -IETF RFC 2205 -End-to-End QoSを動的にサポート -帯域予約は方方向 -IPヘッダー46 -PathパケットはSession, Sender-TSpec,PHOPの情報をPathメッセージとしてNext Hopのルーターに渡す。 --Sessionは宛先IP,Port,UDP/TCP --Sender-TSpecは特定のコーデックに必要な最大帯域数を指定 --PHOPは処理したIPアドレス -Next HopルータがRSVP非対応の場合は透過 -ResvパケットはSession,NHOPを返信 *RSVPへの移行 -CUCMは最初にRSVPがEnableになっているか確認してからLBMによってロケーションとリンクを確認するため容易に移行が可能。 -1) &bold(){Default inter-location RSVP Policy}がenableになっている確認 -2) デバイスのMRGLからRSVPエージェントを割り当て、RSVP予約リクエストを行う -3) RSVPエージェントから結果を受け取る -4) CUCMはCACがEnable(LBMがActive)か確認し、Enableの場合は有効なリンクから帯域確保を要求 -5-1) 要求がOKだと、コールを開始する -5-2) 要求がNGだと、&bold(){Call Treatment When No LBM Available}の設定を確認し、Callを許可する場合(&bold(){allow call})はコールを開始 *RSVPの設定(CUCM) -Default inter-location RSVP PolicyをMandatory かMandatory(Video Desired)に変更 -各拠点でRSVPエージェントを設定 -MRGおよびMRGLにRSVPエージェントを割り当て -Call Treatment When No LBM AvailableをAllow Callに設定 -Default inter-location RSVP PolicyをMandatoryかMandatory(Video Desired)に変更 *RSVPへの移行完了後の確認項目 -LBMをDisableにする -問題が発生したら、Default inter-location RSVP PolicyをNo Reservationへ変更 *SCCP(アプリケーションID) -RSVPでアプリケーションごとの帯域確保を行う(音声かビデオ) -12.4(6)T以降のIOSでサポート -アプリケーションIDはRSVP Audio Application IDとRSVP Video Application IDのパラメータで設定 -CUCMはSCCPを使ってRSVPエージェントに送る -RSVPエージェントはRSVPシグナルパケット(PATH/RCEV)にアプリケーションIDを付与して送付 -ビデオコール(音声とビデオ)の場合はVideo Application IDを使用する *SIPプレコンディション -RFC3312とRFC4032に基づく -RSVPメッセージはSIPトランクでは使われず、ポリシー情報をSIPパケットに乗せて送る -SIPプレコンディションでは事前にSDPパケットを送る。下記の場合は、現在のQoSの設定をnoneからend-to-end Mandatory sednrecvに変更し、呼び出し音を鳴らす前にネゴする。 SDP Packet(INVITE) SDP Packet (UPDATE) a=curr:qos e2e none a=curr:qos e2e send a=des:qos mandatory e2e ==> a=des:qos mandatory e2e sendrecv sendrecv *クラスタ対応 -クラスタ間をSIPでつなぐと、End-to-EndでRSVPが有効になる（Ciscoでは推奨していない。） -SIPトランクプロファイルで&bold(){Fall back to local RSVP}を設定するとEnd-to-EndからローカルのRSVPにきり戻す設定が可能 -対向からSIP 420(Bad Extension)が帰ってきた場合のみ。 -対向からSIP 580(Precondition Failed)の場合はフォールバックしない &link_back() &link_edit()

CISCO/CCIE Voice/Voice 設定/RSVP

2014-01-04T13:24:44+09:00

&topicpath() #ls() *RSVPの設定 ip rsvp bandwidth [最大I/F帯域kbps] [最大1コール帯域kbps] -設定していないインターフェイスではRSVPパケットをドロップするため注意 -インターフェイスでCACしない場合は、75％の帯域幅で設定 -SRTPなどの場合のオーバーヘッドは考慮されていない。 -初期予約と更新後で使用する帯域幅が異なるため、初期予約の分も考慮が必要。 -WAN(MPLS)で非対称ロードバランスをする際は注意が必要。 -DMVPNでの設定も可能 -percent設定も可能(MLPPPやLAG)の場合 *RSVP Intservの場合 -コントロールプレーンとデータプレーンの両方でRSVPを使う場合(Intserv) ip rsvp resource-provider wfq [interface | pvc] no ip rsvp data-packet classification -LLQと一緒に使う場合は、LLQで確保する帯域とRSVPで確保する帯域は合わせてリンクの75％まで。 -RSVPで確保した帯域の中で更にPQを使う場合は下記。 ip rsvp pq-profile[トラフィックの平均レート(bytes/sec) [フローの最大バースト(bytes) [ピークと平均レートの比率(%)] ] ] -パラメータを設置しない場合は G.711の最大値である、12,228byte/sec, 592bytes, 110%　を使用する *RSVP Intserv/Difserv -コントロールプレーンはRSVP, データプレーンはLLQ -ip rsvp bandwidth はLLQのPQの一部に組み込まれる -優先する帯域の全てをRSVP用のパケットで使う場合は RSVP=PQで帯域幅を設定 ip rsvp resource-provider none ip rsvp data-packet classification none -RSVP用のトラフィックは適切にDSCPをマーキングする。 -RSVP用以外のトラフィックをPQに含めたい場合は、RSVP+RSVP以外のトラフィックがPQ/CBWFQで設置している帯域幅にあうこと。 ---- &link_back() &link_edit()

CISCO/CCIE Voice/Voice 基礎

2014-01-04T05:51:11+09:00

&topicpath(top=Cisco) #contents_line(sep=/) *コーリングサーチスペース (CSS) -特定のデバイスからどのパーティションがアクセスできるか指定する -コールできない場合はビジートーンが聞こえる -回線とデバイスと二つCSSがある場合は統合してデバイスCSSの前に回線CSSをおく。 -デバイスモビリティがない場合は同じCSSを使用。 -デバイスモビリティを使う場合は、IPアドレスを元にCSSをダイナミック(動的)にアサイン。 -CSSの文字数は少なめにするのがベター。CSSの最大文字数は512文字。デバイスと回線の統合後は1024文字 -DNのパーティションとCSSの初期設定は。があると動作がおかしくなる。 -トランスフォーメーションパターンのパーティションは特殊。 *パーティション -ルートパターンとDN(電話番号)をグループ化したもの。 *ルートパターンについて | 1 |ルートパターン|番号一致・ルートリストの選択・場合によっては番号操作| | 2 |ルートリスト|優先ルートグループを指定・ルートグループの番号を操作・コールパスの選択| | 3 |ルートグループ|コールをゲートウェイ・もしくはトランクに渡す| | 4 |トランスフォーメーションパターン|発信者変更・着信者変更| -ルートリストはルートパターンの@(ワイルドカード)と一緒に使う。 *トランスフォーメーションパターン -一番強力な番号操作 -ルートパターンとほぼ同じようにパーティションに割り当てるが、外部トランクへはルーティングせず、番号操作後にCSSに戻す。 -CDRも変更後の番号が残るが、IP Phoneにはコールしたオリジナルの番号が残る -コールルーティングの動作動作順序は 1->2->3->4 設定順序は 4->3->2->1 #image(http://cdn54.atwikiimg.com/latte05/?cmd=upload&act=open&page=CISCO%2FCCIE%20Voice&file=callrouting.PNG) &link_back() &link_edit()

SwAN DiVE 別館 実験室