トラブルシューティングにより、この問題は特定のシナリオに存在することが明らかになりました。 問題は、クライアントに提供される番号のプールに発信者番号が含まれていない場合、プロバイダーが発信呼び出しをルーティングしないことです。
この問題の詳細な説明と解決策については、詳しく説明しません。
問題の説明
Lyncインフラストラクチャをテレフォニーにドッキングするスキーム：
ダイアグラムは示します ：
- PBX Nortel CS1000;
- Audiocodes Mediation 1000、v 6.60;
- Lync 2013 cフロントエンド、調停。
次の図は、可能なコール転送シナリオを示しています。
凡例 ：
- N-PBX Nortel;
- A-オーディオコード;
- N1、N2-Nortel PBXサブスクライバー。
- L1-Lyncサブスクライバー（スキームを簡素化するために、Lyncサーバーは意図的に表示されていません）;
- P-テレフォニープロバイダー。
- E1、E2-外部サブスクライバー。
- 赤枠は、Lyncサブスクライバーからの通話が転送されるサブスクライバーです。
シナリオ＃3では、発信者番号「E1」が組織に登録されていないため、プロバイダーは組織からの発信通話を「切断」します。 良好な場合、プロバイダーは適切なルートで通話を行い、History-infoフィールドに従って課金システムに入力する必要があります。 しかし、この場合、プロバイダーはHISTORY-INFOフィールドを受け入れません。プロバイダーの課金システムの作業は、FROM、TO属性のみに基づいて構築されます。
次のSIP Invite要求は、AudiocodesのLync Mediationから受信されます。
FROM: <sip:"E1";phone-context=enterprise@domain.net;user=phone>;epid=7B11BD1265;tag=8c9e1f2146 TO: <sip"E2"@voice_gw.domain.net;user=phone>CSEQ: 329 INVITE HISTORY-INFO: <sip:"L1"@lyncmediation1.domain.net;user=phone>;index=1;ms-retarget-reason=forwarding,<sip:"E2"@lyncmediation1.domain.net;user=phone>;index=1.1
問題の声明
ソリューションオプション ：
- リサイクルプロバイダーの課金システム。
- 特別なプレフィックスを付けてルートを作成し、そのルートで「発信者IDを隠す」パラメーターを有効にして、「代替発信者ID」を設定します。 プレフィックスが割り当てられた転送番号を入力するようユーザーに促します。
- ここで説明されているように、SIPメッセージ操作ルール機能を使用します。 （同様のソリューションがベンダーサポートによって提案されました）。
最初のオプションは試されさえしませんでした。
2番目と3番目のオプションでは、プラスよりもマイナスが多くなります。 スクリプト＃3は修正されていますが、同時にスクリプト＃1、2、4では便利な機能が失われています。転送されたすべてのコールは、コール転送がアクティブになっている番号から発信されます。
3番目のオプションを使用して決定しました。
「E1」および「E2」が外部番号であるメッセージの場合、メッセージ操作ルールを使用して、FROMフィールドの値をsip：「E1」からsip「L1」に置き換える必要があります。
他のシナリオでは、機能の損失につながるため、このルールを適用しないでください。 リダイレクトされたコールを受信する加入者には、発信者の実際の発信者IDは表示されません。
置換ルールの呼び出し番号のアクティブ化テーブル ：
| ＃ | から | 転送先（履歴情報） | IsRuleNeedToBeApplied |
|---|---|---|---|
| 1 | 内部 | インターナ | 偽 |
| 2 | 外部 | 内部 | 偽 |
| 3 | 外部 | 外部 | TRUE |
| 4 | 内部 | 外部 | 偽 |
表の説明 ：
- 発信者番号と転送番号が外部の場合にのみ、置換ルールをアクティブにする必要があります。
- 内部eq + 7717212XXXX、組織に登録されている番号。
- 外部eq + 7717212XXXXではなく、組織に登録されていない名前。
- ＃1 ルーティングは内部的に実行されるため、ルールを適用する必要はありません。 プロバイダーフィルターが有効になっていません。
- ＃2 CallingNumber（FROM）は組織に登録されているため、ルールを適用する必要はありません。 プロバイダーフィルターは有効になっていますが、呼び出しはブロックされません。
- ＃3 ルーティングは内部的に実行されるため、ルールを適用する必要はありません。 プロバイダーフィルターが有効になっていません。
- ＃4。 ルールを適用する必要があります。 プロバイダーフィルターが有効になっている場合、CallingNumber（FROM）を代用しないと、通話はブロックされます。
解決策
構成 ：
- xxxx / AdminPageでINIパラメーターページを開きます。 SetID SetID。このためには、パラメータ名フィールドにGWINBOUNDMANIPULATIONSETと入力し、値を入力フィールドに対応するSetID番号を入力します。
- VOIP> SIP Defenitions> Message Manipulationsで次の表に説明されているルールを作成します。
ルール表 ：
| Indx | ID | メッセージタイプ | 状態 | アクトゥビ | ActType | 行為価値 | ロウレ |
|---|---|---|---|---|---|---|---|
| 1 | 1 | 誘う | header.history-info正規表現（sip：\ + 7（717212 ....）@） | var.call.src.0 | 修正する | 2ドル | 0 |
| 2 | 1 | 誘う | header.to regex（sip :(？！717212）（。*）@） | var.global.0 | 修正する | 「1」 | 0 |
| 3 | 1 | 誘う | header.from regex（sip :(？！717212）（。*）@） | header.from.url.user | 修正する | var.call.src.0 | 0 |
ルール番号1は、HISTORY-INFOヘッダーがあるかどうかを確認し、内線番号テンプレートに対応するグループを形成し、このグループをvar.call.src.0変数に書き込みます。 この変数は、ヘッダーheader.from.url.userの発信者番号を置き換えるために3番目のルールで使用されます。
ルール番号2は、外部番号のTOヘッダーをチェックします。 正規表現関数「Negative lookahead」が使用され、プレフィックス717212によってローカル番号が除外されます。肯定的な結果の場合、変数var.global.0が書き込まれます。 この変数には何の役割もありません。
ルール3は、外部番号のFROMヘッダーをチェックします。 プレフィックス717212でローカル番号を除外する正規表現関数「負の先読み」が使用されます。肯定的な結果の場合、ステップ1で記録された変数var.call.src.0がヘッダーheader.from.url.userの着信番号を置き換えるために使用されます。
結果
シナリオ3では、発信者番号が転送の開始者の番号に変更されます。
他のシナリオでは、発信者番号は変更されません。
付録1.構成リスト
GWINBOUNDMANIPULATIONSET = 1 [ MessageManipulations ] FORMAT MessageManipulations_Index = MessageManipulations_ManSetID, MessageManipulations_MessageType, MessageManipulations_Condition, MessageManipulations_ActionSubject, MessageManipulations_ActionType, MessageManipulations_ActionValue, MessageManipulations_RowRole; MessageManipulations 1 = 1, "invite", "header.history-info regex (sip:\+7(717212....)@)", "var.call.src.0", 2, "$2", 0; MessageManipulations 2 = 1, "invite", "header.to regex (sip:(?!717212)(.*)@)", "var.global.0", 2, "'1'", 0; MessageManipulations 3 = 1, "invite", "header.from regex (sip:(?!717212)(.*)@)", "header.from.url.user", 2, "var.call.src.0", 0; [ \MessageManipulations ]