11

モバイル ネットワーク プロバイダーが作成した Windows デスクトップ アプリケーションを使用しています。このアプリケーションは、SIP を使用してあらゆる種類の処理を行います: 通話、メッセージの送信など。このアプリが正常に送信する方法のスクリーンショットMESSAGE(最後の 4 行): ワイヤーシャーク

MESSAGEデスクトップ アプリケーションからのリクエストは、(後ろから 4 行目) として送信されます。

MESSAGE sip:FROM@DOMAIN SIP/2.0
Via: SIP/2.0/UDP LOCALIP:2112;branch=z9hG4bK-d8754z-905183245f478c76-1---d8754z-;rport
Max-Forwards: 70
To: "TO"<sip:TO@DOMAIN>
From: "FROM"<sip:USERNAME@DOMAIN>;tag=63088d09
Call-ID: NGVhMDJhYzQwNmExOTQyNThmNjc5OGNmOTViNDUyYWM.
CSeq: 2 MESSAGE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: text/plain
Content-Length: 4

test

それに対する成功した応答は次のとおりです。

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP LOCALIP:2112;received=EXTERNALIP;branch=z9hG4bK-d8754z-905183245f478c76-1---d8754z-;rport=2112
To: "TO"<sip:TO@DOMAIN>;tag=c005f0e30133ec730add76fc91f4bea
From: "FROM"<sip:USERNAME@DOMAIN>;tag=63088d09
Call-ID: NGVhMDJhYzQwNmExOTQyNThmNjc5OGNmOTViNDUyYWM.
CSeq: 2 MESSAGE
Content-Length: 0
Proxy-Authenticate: Digest nonce="3F178051B97E1F52000123000A3C53D4B",realm="DOMAIN",algorithm=MD5,qop="auth"

次に、PHP から同一の (および n バリエーション) リクエストを送信しようとしますが、SIP/2.0 403 Forbidden代わりに常に受信しますSIP/2.0 407 Proxy Authentication Required:

SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP LOCALIP;received=EXTERNALIP
To: "TO"<sip:TO@DOMAIN>;tag=aprqngfrt-f7ccjj0000020
From: "FROM"<sip:USERNAME@DOMAIN>;tag=8f7be81d
Call-ID: 526576901edcc@localhost
CSeq: 1 MESSAGE
Reason: Q.850;cause=55;text="Call Terminated"
Content-Length: 0

おもしろいのは、リクエストを送信すると機能し、ヘッダーREGISTERを正常に受信することです。オーソリを再計算し、再送信します。それから私は受け取ります。それはどのように動作するはずです。SIP/2.0 401 UnauthorizedWWW-AuthenticateSIP/2.0 200 OKMESSAGE

何が間違っている可能性がありますか？私は何を取りこぼしたか？MESSAGEその前にリクエストに他のリクエストが必要ですか（私はすでに試しましREGISTERた）？RFC 3428を上下に
読み、可能なすべての例を試しましたが、成功しませんでした。

4

2 に答える 2

6

受信した 403 応答を調べると、Reason ヘッダーに気付くでしょう。先頭の Q.850 文字列は、これが ITU-T 勧告によって定義された原因コードであることを示しています。

具体的には、提供された原因コード 55 は ISDN に関連しており、文字通り「非公開ユーザー グループ内で着信通話が禁止されている」( RFC 3398で確認できます) という意味であり、通常、メンバーのグループ内で着信が制限されていることを意味します。

一方、原因 55 は、特にユーザー (送信者または受信者) に関連する、要求内の問題も示します。次の図は、SIP ユーザー間の通常の MESSAGE 交換を示しています。

      A             Server             B
      |    REGISTER    |               |
      |--------------->|               |
      |     200 OK     |               |
      |<---------------|               |
      |                |    REGISTER   |
      |                |<--------------|          
      |                |     200 OK    |
      |                |-------------->|
      |    MESSAGE     |               |
      |--------------->|    MESSAGE    |
      |                |-------------->|
      |                |     200 OK    |
      |                |<--------------|
      |     200 OK     |               |
      |<---------------|               |

実際には厳密に言えば、ユーザー A からの REGISTER は必要ありませんが、ほとんどのシステム (IMS など) はこれを認証メカニズムとして使用しています。次に、REGISTER 要求では、特別なヘッダーは次のとおりです。

Contact: <sip:USER_NAME@LOCAL_IP:LOCAL_PORT>
Expires: REGISTRATION_DURATION

REGISTER に対する 200 OK の回答には、受け入れられた有効期限を示すExpires:ヘッダーまたはヘッダーexpires内のパラメーターを含めることができることに注意してください。例えば：Contact:

SIP/2.0 200 OK
...
Contact: <sip:USER_NAME@LOCAL_IP:LOCAL_PORT>; expires=60 
...

この状況では、この有効期限 (例では 60 秒) の前に再登録する必要があります。

SMS を携帯電話に送信しようとしていることに注意してください。受信ポイントは、ネットワーク プロバイダーのMGCFによって直接管理されているため、送信者の登録または MESSAGE 要求が残されます。

元の MESSAGE 提案について、リクエスト URI (メッセージの最初の行) は次のようにする必要があります。

 MESSAGE sip:TO@DOMAIN SIP/2.0

MESSAGE受信実体を指すからです。

お役に立てれば。

于 2013-12-07T15:57:59.610 に答える