Rust言語の学習のために簡易なSIP Stateless Proxy Serverをさくっと実装してみる

この記事は [NTTコムウェア Advent Calendar 2023](https://qiita.com/advent-calendar/2023/nttcomware) 24日目の記事です。

NTTコムウェアの近江です。
皆様は新しいプログラミング言語を学ぶときにどのように学習を進めますか？基本文法を学んだあとは何かしら作ってみたいけれど、さて何を作ろう？と迷うことはないでしょうか。
そんな悩みを知人に相談したところ、通信を行うソフトウェアを実装することを勧められました。同じプロトコルを具備した他のソフトウェアと通信させることで正しさを確認できるから、だそうです。

この記事は、遅ればせながら以前より気になっていた[Rust](https://www.rust-lang.org/)を用いて、VoIPで使われることが多いプロトコルである[SIP](https://www.rfc-editor.org/rfc/rfc3261.txt)で規定されているStateless Proxyを元に、私の独断と偏見で**ギリ通信できる程度に要件を削ぎ落としまくった**なんちゃってStateless Proxyの実装を進めていった際の検討や調査のメモ、あるいは[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)を独自に解釈してプログラミングを楽しんだ記録です。


:::note warn
私自身今回初めて[Rust](https://www.rust-lang.org/)言語を触るのと、[SIP](https://www.rfc-editor.org/rfc/rfc3261.txt)も昔趣味で調べた程度です。誤りやより効率のよい方法、あるいはそれでも動くけれど慣習的にそうは書かないよ、などなど、なにかあれば是非コメントを頂戴できればと思います。
:::

:::note warn
本記事はIETFのRFCを多数引用しています。記事にする際に読みにくくなる場合には、意味が変わらない範囲で空白文字やページ区切りを削除、記述順序の入れ替えなどをしていることがあります。
:::

# プロジェクトを作る

プロジェクトの名称は、プロキシに適した名前として直感で「sotafugy8」という名づけることにしました。この名前に特に意味はなく、個人的にプロキシ感を感じることができた語感のみで決めました。以降、今回実装するものについて言及する先にはsotafugy8と表記します。

事前に[Rustの環境は整えられている](https://www.rust-lang.org/learn/get-started)前提で、sotafugy8というプロジェクトを作ります。

```bash
cargo new sotafugy8
```

これによりこのコマンドを実行したディレクトリ内にsotafugy8というディレクトリが生成され、さらにその中に生成されたsrcディレクトリ内にmain.rsというソースファイルが生成されているので、このファイルにコードを書いていきます。

sotafugy8が依存するクレートがいくつかあるので、Cargo.tomlに書いておきます。（後で書いてもかまいません）

```diff_toml
[dependencies]
+ regex = "1.10.2"
+ lazy_static = "1"
+ md5 = "0.7.0"
```


# つくるもの

[SIP](https://www.rfc-editor.org/rfc/rfc3261.txt)のシーケンス例が[RFC3665](https://www.rfc-editor.org/rfc/rfc3665.txt)にいくつか記載されています。
分かりやすそうな例として、[RFC3665](https://www.rfc-editor.org/rfc/rfc3665.txt)「3.4.  Successful Session with Proxy Failure」のシーケンスの後半を切り取って以下に示します。（なお、Proxy 2はStateful Proxyの動作になっています。Stateless Proxyの場合は若干異なり、`F13`の信号を自ら送信することはしません。またsotafugy8では`F18`以降の信号はProxyを経由せずに送信されるように実装します。）

```
    Alice                            Proxy 2            Bob
      |                                 |                |
      |           INVITE F11            |                |
      |-------------------------------->|   INVITE F12   |
      |             100  F13            |--------------->|
      |<--------------------------------|                |
      |                                 |     180 F14    |
      |             180 F15             |<---------------|
      |<--------------------------------|                |
      |                                 |     200 F16    |
      |             200 F17             |<---------------|
      |<--------------------------------|                |
      |             ACK F18             |                |
      |-------------------------------->|     ACK F19    |
      |                                 |--------------->|
      |                Both Way RTP Media                |
      |<================================================>|
      |                                 |     BYE F20    |
      |             BYE F21             |<---------------|
      |<--------------------------------|                |
      |             200 F22             |                |
      |-------------------------------->|     200 F23    |
      |                                 |--------------->|
      |                                 |                |
```

具体的な信号も同じ[RFC3665](https://www.rfc-editor.org/rfc/rfc3665.txt)「3.4.  Successful Session with Proxy Failure」に記載されており、その中でProxyの役割がわかりやすいところとして、F11とF12の箇所のメッセージを以下に引用します。

`F11 INVITE Alice -> Proxy 2`

```
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Proxy-Authorization: Digest username="alice",
 realm="biloxi.example.com",
 nonce="1ae6cbe5ea9c8e8df84fqnlec434a359", opaque="",
 uri="sip:bob@biloxi.example.com",
 response="8a880c919d1a52f20a1593e228adf599"
Content-Type: application/sdp
Content-Length: 151

v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
```

`F12 INVITE Proxy 2 -> Bob`

```
INVITE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss2.biloxi.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:alice@client.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 151

v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
```

見比べると、

* proxyを通る前後でINVITEという文字列の右側が```sip:bob@biloxi.example.com```から```sip:bob@client.biloxi.example.com```に変わっている
* Viaで始まる行が１行増えている
* 元々あったViaで始まる行の次の行にスペースをひとつおいた後に```;received=```で始まる行が追加されている
* Max-Forwardsで始まる行の数字が１減っている

などの差分があリます。(他にも差分がありますが、それらを扱う機能はsotafugy8では実装しません）

また、先ほどのメッセージはリクエストと呼ばれるものの一種なのですが、それに対するレスポンスの例としてF16とF17を以下に引用します。


`F16 200 OK Bob -> Proxy 2`

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
 ;received=192.0.2.222
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
Record-Route: <sip:ss2.biloxi.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147

v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
```

`F17 200 OK Proxy 2 -> Alice`

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
Record-Route: <sip:ss2.biloxi.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 4Fde34wkd11wsGFDs3@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Content-Type: application/sdp
Content-Length: 147

v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
```
`F16`に比べると`F17`は

* Viaで始まる行が一行減っている

ことがわかります。

以上のように、Proxyは受信したリクエストもしくはレスポンスを一部編集しつつ別の誰かに中継する、という機能を提供します。


Proxyの詳しい要件については[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 91から始まる「16 Proxy Behavior」に書いてありますが、今回はあくまでも[Rust](https://www.rust-lang.org/)言語の学習が主な目的なので、先ほども述べた通り、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)で定義されている本来のProxyではなく、私自身の独断と偏見で勝手に要件を落としまくったミニマムスペックにすら達していないStateless Proxy的な何かを実装していきます。実装する／しないの主な判断基準を以下に記しておきます。

* 下位レイヤのプロトコルはUDP/IPv4のみにする
* マルチキャスト対応しない
* 通信相手がRFC3261に準拠しているものと想定する
* 受信したメッセージを解析する際には厳格にはチェックせず、ゆる～く解析する
* addr-specはSIP-URIだけに対応
* リクエスト中継時にRecord-Routeは挿入しない
* 拡張機能の類には一切対応しない
* 認証関連機能には一切対応しない（※簡単にイタズラできちゃいます）
* RegistrarとLocation Service機能も内包する
* REGISTERで登録できるアドレスはひとつだけ、優先順位を指定しても無視
* REGISTERで登録したアドレスは有効期限切れしない
* 同じ意味になるが異なる表現ができる文字列を比較する際に完全一致の比較のみを行う
* フリーのSIPソフトフォンを探してきて通話できればそれでよしとする



# メッセージの受信

メッセージの受信を契機に諸々の処理が動き始めるので、まずは受信から実装していきます。
[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 142に

```
  All SIP elements MUST implement UDP and TCP.  SIP elements MAY
  implement other protocols.
```

と書いてあり、UDPだけでなくTCPへの対応も必須ということになっていますが、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 143に

```
  If an element sends a request over TCP because of these message size
  constraints, and that request would have otherwise been sent over
  UDP, if the attempt to establish the connection generates either an
  ICMP Protocol Not Supported, or results in a TCP reset, the element
  SHOULD retry the request, using UDP.  This is only to provide
  backwards compatibility with RFC 2543 compliant implementations that
  do not support TCP.  It is anticipated that this behavior will be
  deprecated in a future revision of this specification.
```

と書いてあり、行儀のよい[SIP](https://www.rfc-editor.org/rfc/rfc3261.txt)クライアントであればTCPでの通信に失敗したらUDPで送ってくれそうなので、相手に甘えることにしてUDPだけに対応します。また、IPv4のみに対応し、IPv6には対応しません。（なお、IPv6対応したい場合は[RFC5954](https://www.rfc-editor.org/rfc/rfc5954.txt)も参照したほうがよさそうです）

UDPを使ってパケットを受信するには、以下のようなコードを書けばよいようです。

```rust
let hostport = format!("{}:{}", ip, port);
let sock = UdpSocket::bind(hostport).unwrap();
let mut buf = [0; 0xffff];
if let Ok((rsize, saddr)) = sock.recv_from(&mut buf) {
    // saddrから送られてきたデータがbufにrsizeバイト分格納されている
}
```

これをうまいことコードに組み込んでいきます。

# 文字列に変換

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 26に```SIP is a text-based protocol and uses the UTF-8 charset```と書いてあるので、受信したデータを文字列に変換します。

先ほどのコードを利用しつつProxyという構造体(struct)を作り、その中でUDPで受信した後にUTF-8に変換するコードを追加しておきます。self.proc()はあとで実装します。

```rust
// プロキシ
struct Proxy {
    ip: String,
    port: u16,
    sock: UdpSocket,
    locs: HashMap<String, String>,
}

impl Proxy {
    fn new(ip: &str, port: u16) -> Self {
        let hostport = format!("{}:{}", ip, port);
        Self {
            ip: String::from(ip),
            port: port,
            sock: UdpSocket::bind(hostport).unwrap(),
            locs: HashMap::new(),
        }
    }

    fn run(&mut self) {
        let mut counter = 0;
        let mut buf = [0; 0xffff];
        loop {
            if let Ok((rsize, saddr)) = self.sock.recv_from(&mut buf) {
                if let Ok(s) = std::str::from_utf8(&buf[..rsize]) {
                    self.proc(s, saddr);
                    counter += 1;
                    println!("{}", counter);
                }
            }
        }
    }

    fn proc(&mut self, s: &str, saddr: SocketAddr) -> Option<()> {
        // あとで実装
    }
}
```

なお、SIPメッセージにはmessage-bodyと呼ばれる部分があるのですが、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 33に以下のような記述があり、message-bodyはバイナリでもよいとされているので、本気でSIPスタックを実装するのであれば文字列に変換する前にmessage-bodyを抽出しておくべきでしょう。

```
  SIP messages MAY contain binary bodies or body parts.
```

# SIPメッセージをざっくり解析

Proxyとして信号を中継するにあたり、のちに受信した信号の中身を一部編集したり、中身をみて中継先を判定したりすることになるのですが、都度信号を解析するとコードが複雑になったり処理時間が長くなったりしそうな気がするので、まずは大まかに解析しておくことにします。

SIP信号のフォーマットは[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 27に以下のような構成になっていると書いてあります。

```
  A SIP message is either a request from a client to a server, or a
  response from a server to a client.

  Both Request (section 7.1) and Response (section 7.2) messages use
  the basic format of RFC 2822 [3], even though the syntax differs in
  character set and syntax specifics.  (SIP allows header fields that
  would not be valid RFC 2822 header fields, for example.)  Both types
  of messages consist of a start-line, one or more header fields, an
  empty line indicating the end of the header fields, and an optional
  message-body.

        generic-message  =  start-line
                            *message-header
                            CRLF
                            [ message-body ]
        start-line       =  Request-Line / Status-Line

  The start-line, each message-header line, and the empty line MUST be
  terminated by a carriage-return line-feed sequence (CRLF).  Note that
  the empty line MUST be present even if the message-body is not.
```

これに相当する説明＋αを[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 219から始まる「25  Augmented BNF for the SIP Protocol」に定義されているBNFから抜き出してまとめてみました(以降、BNFに関して記載するときはいずれもこのセクションからの引用です)。```※中略※```と書いた箇所は、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)でそれぞれの意味が言及されているヘッダのフォーマットが書かれているのですが、現段階で実行する解析に必要なフォーマット情報としてはextension-headerに包含されるように見えたので、extension-headerだけを転記しました。


```
SIP-message    =  Request / Response
Request        =  Request-Line
                  *( message-header )
                  CRLF
                  [ message-body ]
Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
Response          =  Status-Line
                     *( message-header )
                     CRLF
                     [ message-body ]
Status-Line     =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
message-header  =  (
                   ※中略※
                /  extension-header) CRLF
extension-header  =  header-name HCOLON header-value
header-name       =  token
header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)
message-body  =  *OCTET
```

これらを踏まえ、解析完了時に[Rust](https://www.rust-lang.org/)の以下のような構造体の中身が埋まっている状態を目指すことにします。

```rust
struct Message {
    method: String,    // start-line(Request-Line)のMethod
    requri: String,    // start-line(Request-Line)のRequest-URI
    stcode: String,    // start-line(Status-Line)のStatus Code
    reason: String,    // start-line(Status-Line)のReason Phrease
    hdrs: Vec<Header>, // message-headers
    body: String,      // message-body
}

struct Header {
    name: String,      // header-name
    vals: Vec<String>, // header-value
}
```

前述のBNFからもわかりますが、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 27に以下のように書かれていて、Request-LineもStatus-Lineもmessage-headerもCRLFで終端していて、message-headerのあとにはさらにCRLFが続いていることがわかります。

```
  The start-line, each message-header line, and the empty line MUST be
  terminated by a carriage-return line-feed sequence (CRLF).  Note that
  the empty line MUST be present even if the message-body is not.
```

CRLFとは、[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のPage 11に書いてある通り、CRとLFが連続している文字列です。CRは同じく[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のPage 11に書いてある通りアスキーコードの0x2D、いわゆる\rのことで、LFも[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のPage 11に書いてある通りアスキーコードの0x0A、いわゆる\nのことを指しています。したがってCRLFは\r\nのことになります。上の文章にも```a carriage-return line-feed sequence```と書いてありますし、まぁ、そりゃそうだという感じですね。

ちなみに[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 257に以下のように書かれており、[SIP](https://www.rfc-editor.org/rfc/rfc3261.txt)の古い仕様書にあたる[RFC2543](https://www.rfc-editor.org/rfc/rfc2543.txt)ではCRLFはCR単体やLF単体も許容されていたのだけれども、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)ではCRLFでないとダメということになっています。逆にいうと、[RFC2543](https://www.rfc-editor.org/rfc/rfc2543.txt)にしか対応していない相手とも通信したい場合は単体のCRや単体のLFにも対応する必要がありますが、このsotafugy8では相手が[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)準拠であることを期待し、CRLFのみを許容することにします。

```
  o  In RFC 2543, lines in a message could be terminated with CR, LF,
     or CRLF.  This specification only allows CRLF.
```

[SIP](https://www.rfc-editor.org/rfc/rfc3261.txt)のBNFを熱心に読み込んでいくと、message-headerにはそれらを終端するCRLF以外にもCRLFが登場する場合がありますが、その場合はLWSというものに限定されていているようです。LWSは[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 220に以下のように書いてあります。

```
  LWS  =  [*WSP CRLF] 1*WSP ; linear whitespace
```

WSPの定義は[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)には見当たらないのですが、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 219に

```
  Section 6.1 of RFC 2234 defines a set of core rules that
  are used by this specification, and not repeated here.
```

と書いてあるので、[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)をみてみると、そのPage 12に以下のようにかいてあり、

```
  WSP            =  SP / HTAB
```
SPは[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のPage 11に以下のようにかいてあるとおりいわゆる半角スペースのことで、

```
  SP             =  %x20
```

SPは[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のPage 11に以下のようにかいてあるとおりいわゆる水平タブのことであるというのがわかりました。

```
 HTAB           =  %x09
```

以上から、start-lineやmessage-headerの区切りとなるCRLF以外にCRLFが登場する場合は、その後に必ず半角スペースか水平タブが登場することがわかります。

そこで文字列をその後に半角スペースか水平タブが続いて**いない**CRLFごとに区切り、そのひとつ目をstart-line、ふたつ目以降をmessage-headerたちとして抽出するメソッドをMessage構造体に作ってみました。同時にmessage-bodyも取り出します。途中でエラーによる条件分岐などを書かずに```?```で処理しているところがありますが、この程度の解析に失敗する場合はエラーレスポンスを生成することもできないので、さくっとエラーにして終わらせています。ここでは入力を&strにして解析していますが、もしmessage-bodyとしてバイナリを許容するのであればこのメソッドを改造する必要があります。

```rust
    // SIPメッセージ全体をstart-line、message-header、bodyへの分割を想定
    fn split(buf: &str) -> Option<(&str, Vec<&str>, &str)> {
        let mut pos = 0;
        let mut margin = 0;
        let mut lines: Vec<&str> = vec![];
        static CRLF: &str = "\r\n";
        loop {
            let tmp = buf[pos+margin..].find(CRLF)?;
            if tmp == 0 {
                // empty-line
                break
            }
            let next_line: &str = &buf[pos+margin+tmp+CRLF.len()..];
            if next_line.starts_with(" ") || next_line.starts_with("\t") {
                margin += tmp + CRLF.len();
            } else {
                lines.push(&buf[pos..pos+margin+tmp]);
                pos += margin + tmp + CRLF.len();
                margin = 0;
            }
        }
        let sl = lines.remove(0); // start-lineを抜き出す
        Some((sl, lines, &buf[pos + 2..])) // 2は"\r\n"の長さ
    }
```

なお、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 34に

```
  Implementations processing SIP messages over stream-oriented
  transports MUST ignore any CRLF appearing before the start-line
```

と書いてあり、stream-orientedの場合にはstart-lineの前にCRLFが登場していたら無視しろと言われていますが、sotafugy8ではUDPにしか対応しないので気にしないことにします。


続いてstart-lineを解析します。

start-lineはRequest-lineもしくはStatus-lineのことであり、それらは[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12481行目あたりであったり、

```
Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
```

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12581行目あたりに書いてあります。

```
Status-Line     =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
```

ただし、先ほど書いたsplitというメソッドで最後のCRLFは消えた状態になっています。それぞれの定義は当然[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)に記載されており、とても長くなるのでここに転記はしませんが、以下のような正規表現を使えば取り出せそうな定義になっていました。

```rust
lazy_static! {
    static ref RE_SL: Regex = Regex::new(r"^(([^ ]+) ([^ ]+) )?SIP/2\.0( (\d\d\d) ([^\r\n]+))?").expect("failed to build Regex for Start-Line");
}
```

なお、lazy_staticを使って定義しておくと、この正規表現の解釈を一度しか実行しないようになるのだそうです。正規表現を定義する場所と使う場所が離れるのは個人的には好きではないのですが、この処理は重そうな予感がするので、一度しか実行しないほうを選びました。

これを使ってstart-lineを解析するメソッドをMessage構造体に作ってみました。

```rust
    fn parse_start_line(&mut self, buf: &str) -> Option<()> {
        let cap = RE_SL.captures(buf)?;
        if let Some(m) = cap.get(2) {
            // requestの場合
            self.method = m.as_str().to_string();
            self.requri = cap.get(3)?.as_str().to_string();
        } else if let Some(m) = cap.get(5) {
            // responseの場合
            self.stcode = m.as_str().to_string();
            self.reason = cap.get(6)?.as_str().to_string();
        }
        Some(())
    }
```

続いてmessage-headerを解析します。message-headerは基本的には[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12973行目に書いてあるようなフォーマットになっています。

```
extension-header  =  header-name HCOLON header-value
```

HCOLONは[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12298行目に以下のように書いてあり、

```
HCOLON  =  *( SP / HTAB ) ":" SWS
```
SWSは[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12291行目に以下のようの書いてあり、

```
SWS  =  [LWS] ; sep whitespace
```

LWSのフォーマットについてはすでに説明しました。

これを真面目に処理するならば、正規表現で、```[ \t]*:(([ \t]*\r\n)?[ \t]+)?```とかにマッチさせてそれより前をheader-name、後ろをheader-valueにすればよいのでしょうが、ここでは```:```で区切ってそれより前の文字列のうち後ろにくっついている空白を除いたものをheader-name、後ろの文字列のうち前にくっついている空白を除いたものをmessage-valueにしてみます。Headerという構造体に以下のような関数を作ってみました。

```rust
    fn split(buf: &str) -> Option<(&str, &str)> {
        let vals: Vec<&str> = buf.splitn(2, ":").collect();
        if vals.len() == 2 {
            return Some((vals[0].trim_end(), vals[1].trim_start()));
        }
        None
    }
```

さて、header-valueについて、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 21からPage 22にかけて以下のように書いてあり、comma(`,`)で区切られた複数の値が存在する場合があることがわかります。

```
      Header Field: A header field is a component of the SIP message
         header.  A header field can appear as one or more header field
         rows. Header field rows consist of a header field name and zero
         or more header field values. Multiple header field values on a
         given header field row are separated by commas. Some header
         fields can only have a single header field value, and as a
         result, always appear as a single header field row.
```

このsotafugy8でのちに解析をする可能性があるmessage-headerのうち、Via、Contact、Routeの3種類のヘッダについては、カンマで区切られた複数の要素が載ってくる場合があるものになっています。そこでこれらのヘッダについては、この時点でカンマで区切って```Vec<String>```型で保持することにします。（それ以外のヘッダも```Vec<String>```型でデータを保持したいのですが、特に解析などは行わずにheader-valueを丸ごとひとつの要素に格納することにします。）

では、それらヘッダのフォーマットをもう少し詳しく確認します。
まずViaから。[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)と[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のいろいろな場所からとってきて整理するとこんな具合になります。

```
Via               =  ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm          =  sent-protocol LWS sent-by *( SEMI via-params )
via-params        =  via-ttl / via-maddr / via-received / via-branch / via-extension
via-ttl           =  "ttl" EQUAL ttl
via-maddr         =  "maddr" EQUAL host
via-received      =  "received" EQUAL (IPv4address / IPv6address)
via-branch        =  "branch" EQUAL token
via-extension     =  generic-param
generic-param  =  token [ EQUAL gen-value ]
gen-value      =  token / host / quoted-string
sent-protocol     =  protocol-name SLASH protocol-version SLASH transport
protocol-name     =  "SIP" / token
protocol-version  =  token
transport         =  "UDP" / "TCP" / "TLS" / "SCTP" / other-transport
sent-by           =  host [ COLON port ]
ttl               =  1*3DIGIT ; 0 to 255

quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
quoted-pair  =  "\" (%x00-09 / %x0B-0C / %x0E-7F)

COMMA   =  SWS "," SWS ; comma
DQUOTE         =  %x22
```

じーっと見ると、mesasge-valueに該当する場所は、via-paramがひとつ以上あって、ふたつ以上ある場合はCOMMAで区切られていることがわかります。また、gen-valueはquoted-stringの場合があり、COMMAに必ず現れる```,```のアスキーコードは0x2cに該当するので、qdtextの定義のなかにある```%x23-5B```の範囲に含まれていて、quoted-string内に現れる場合にはDQUOTEとDQUOTEでくくられているということがわかります。

次にContactとRouteについても[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)と[RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)のいろいろな場所からとってきて整理するとこんな具合になります。

```
Contact        =  ("Contact" / "m" ) HCOLON
                  ( STAR / (contact-param *(COMMA contact-param)))
contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
contact-params     =  c-p-q / c-p-expires
                      / contact-extension
c-p-q              =  "q" EQUAL qvalue
c-p-expires        =  "expires" EQUAL delta-seconds
contact-extension  =  generic-param
delta-seconds      =  1*DIGIT

Route        =  "Route" HCOLON route-param *(COMMA route-param)
route-param  =  name-addr *( SEMI rr-param )

name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec      =  SIP-URI / SIPS-URI / absoluteURI
display-name   =  *(token LWS)/ quoted-string
```

こちらもじーっと見ると、message-valueに該当する箇所は、contact-param、rec-route、route-paramがひとつ以上あり、複数ある場合はCOMMAで区切られていて、いずれもgeneric-paramかdisplay-nameがあり、そのなかにquoted-stringがあります。Viaの場合同様にCOMMAに必ず現れる```,```のアスキーコードは0x2cに該当するので、qdtextの定義のなかにある```%x23-5B```の範囲に含まれていて、quoted-string内にある場合にはDQUOTEとDQUOTEでくくられているということがわかります。

以上から、Via, Contact, Routeの３種類のmessage-headerについて、そのheader-valueの部分はDQUOTE（```"```）でくくられていない場所にあるCOMMAで区切ることにします。ちょっと楽をして正規表現で解析することにします。

```rust
    fn parse_hvalue(buf: &str) -> Option<Vec<String>> {
        let mut vals: Vec<String> = vec![];
        let mut pos: usize = 0;
        while buf[pos..].len() > 0 {
            let caps = RE_HVALUE.captures(&buf[pos..])?;
            vals.push(caps.get(1)?.as_str().to_string());
            pos += caps.get(0)?.as_str().len();
        }
        Some(vals)
    }
```

ここで、RE_HVALUEというのは、```Regex```型の変数で、header-valueを取り出すための正規表現です。こんな感じ。

```rust
lazy_static! {
    static ref RE_HVALUE: Regex = Regex::new(r#"^(([^",]|("([^"]|(\"))*"))+)(\s*,\s*)?"#)
        .expect("failed to build Regex for HVALUE");
}
```
ダブルクォーテーションとカンマではない文字か、ダブルクォーテーションのペアで括られているゼロ個以上のダブルクォーテーションではない文字かエスケープされたダブルクォーテーションがひとつ以上続き、そのあとカンマがあってもよく、そのカンマの前後には空白があるかもしれない、ということを表現したつもりです。
この正規表現は厳密な[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の定義に比べるとかなりゆる～くしているので意図的に誤ったフォーマットの文字列を含めると正しいものと誤解させることが可能です。ご注意ください。

では今作ったふたつの関数を使ってmessage-headerを解析するメソッドを書いてみます。

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 32に以下のように書いてあるように、ヘッダ名はcase-insensitiveなので、まず全体を小文字に変換してから小文字同士で比べるようにします。

```
   When comparing header fields, field names are always case-
   insensitive.
```

また、前述のBNFのとおり、ContactヘッダとViaヘッダにはそれぞれm（[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12749行目）とv（[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12943行目）という省略形があるので、それらでもマッチするようにしないといけません。

それらを踏まえ、さきほど示したHeaderという構造体にいくつかのメソッドを定義しました。ついでにデータの設定や取得を行うメソッドも定義しています。

```rust
impl Header {
    fn new() -> Self {
        Self {
            name: "".to_string(),
            vals: vec![],
        }
    }

    // 解析する
    fn parse(&mut self, buf: &str) -> Option<()> {
        let (name, value) = Self::split(buf)?;
        self.name = name.to_string();
        if vec!["via", "v", "contact", "m", "route"].contains(&name.to_lowercase().as_str()) {
            self.vals = Self::parse_hvalue(value)?;
        } else {
            self.vals = vec![value.to_string()];
        }
        Some(())
    }

    // header-nameとheader-valueに分割する
    fn split(buf: &str) -> Option<(&str, &str)> {
        let vals: Vec<&str> = buf.splitn(2, ":").collect();
        if vals.len() == 2 {
            return Some((vals[0].trim_end(), vals[1].trim_start()));
        }
        None
    }

    // header-valueをCOMMAで分割して配列にする
    fn parse_hvalue(buf: &str) -> Option<Vec<String>> {
        let mut vals: Vec<String> = vec![];
        let mut pos: usize = 0;
        while buf[pos..].len() > 0 {
            let caps = RE_HVALUE.captures(&buf[pos..])?;
            vals.push(caps.get(1)?.as_str().to_string());
            pos += caps.get(0)?.as_str().len();
        }
        Some(vals)
    }

    // このヘッダの名前と値を設定する
    fn set(&mut self, name: &str, vals: &Vec<String>) {
        self.name = name.to_string();
        self.vals = vec![];
        for val in vals.iter() {
            self.vals.push(val.to_string());
        }
    }
}
```

最後に、ここまで書いた処理を用いて解析処理全体を実行するメソッドを作っておきます。

```rust
impl Message {
    fn new() -> Self {
        Self {
            method: "".to_string(),
            requri: "".to_string(),
            stcode: "".to_string(),
            reason: "".to_string(),
            hdrs: vec![],
            body: "".to_string(),
        }
    }

    // 解析
    fn parse(&mut self, buf: &str) -> Option<()> {
        // 全体を分割
        let (sl, hdrs, body) = Self::split(&buf)?;
        // Start-Lineの解析
        self.parse_start_line(sl)?;
        // ヘッダの解析
        for h in hdrs.iter() {
            let mut hdr = Header::new();
            hdr.parse(&h)?;
            self.hdrs.push(hdr);
        }
        // ボディの保持
        self.body = body.to_string();
        Some(())
    }
    // 続く
```

先ほど信号受信のところで呼び出したprocというメソッドの中身を書いておきます。
解析した後に、リクエストの場合とレスポンスの場合で異なる処理を実行したいので、そこを呼び出すところも追加しておきます。


```rust
    fn proc(&mut self, s: &str, saddr: SocketAddr) -> Option<()> {
        println!(">>> {} >>>>>>>>\r\n{}", saddr.to_string(), s);
        let mut msg = Message::new();
        if let Some(_) = msg.parse(s) {
            if msg.method != "" && msg.requri != "" {
                self.proc_request(&mut msg, &saddr);
            } else if msg.stcode != "" && msg.reason != "" {
                self.proc_response(&mut msg);
            }
        }
        Some(())
    }

    fn proc_request(&mut self, msg: &mut Message, saddr: &SocketAddr) -> Option<()> {
        // あとで作る
    }

    fn proc_response(&self, msg: &mut Message) -> Option<()> {
        // あとで作る
    }
```

# レスポンスの処理

レスポンスの処理の実装の中で作るメソッドをリクエストの処理でも使用したいので、先にレスポンスの処理から作っていきます。

レスポンス処理については、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の5943行目から始まる「16.7 Response Processing」に説明が書いてあるかと思いきや、「16.11 Stateless Proxy」にこんなことが書いてあります。

```
   Response processing as described in Section 16.7 does not apply to a
   proxy behaving statelessly.  When a response arrives at a stateless
   proxy, the proxy MUST inspect the sent-by value in the first
   (topmost) Via header field value.  If that address matches the proxy,
   (it equals a value this proxy has inserted into previous requests)
   the proxy MUST remove that header field value from the response and
   forward the result to the location indicated in the next Via header
   field value.  The proxy MUST NOT add to, modify, or remove the
   message body.  Unless specified otherwise, the proxy MUST NOT remove
   any other header field values.  If the address does not match the
   proxy, the message MUST be silently discarded.
```
さらにsotafugy8では思いっきり手を抜くことにして、無条件に先頭のViaの値を削除すること、新たに先頭になったViaの値が示す宛先に中継することにします。

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の12943行目あたりにViaヘッダのフォーマットが書いてあります。

```
Via               =  ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
```

受信したメッセージを解析する場所ですでに個別のvia-parmが取り出せているので、先頭のvia-parmの削除は簡単です。
まずは指定されたヘッダを探すためのメソッドをMessageという構造体に実装します。

```rust
    // 指定されたヘッダを探して配列の何番目かを返す。ヘッダ名は小文字で渡すこと。
    fn search(&self, hname1: &str, hname2: &str) -> Option<usize> {
        for (i, hn) in self.hdrs.iter().enumerate() {
            let hname = hn.name.to_lowercase();
            if hname == hname1 || hname == hname2 {
                return Some(i);
            }
        }
        None // 見つからなかった
    }
```

これを使ってViaヘッダを探し、その先頭の値を消します。

```rust
    fn proc_response(&self, msg: &mut Message) -> Option<()> {
        // 先頭のViaを取り除く（リクエスト中継時に自分が挿入したViaのはず）
        match msg.search("via", "v") {
            None => {
                return Some(()); // Viaがないレスポンスは中継できないのでおしまい
            }
            Some(viapos) => {
                // 消す
                msg.hdrs[viapos].vals.remove(0);
                // 消した結果、そのヘッダに値がなくなってしまったら、そのヘッダ自体を消す
                if msg.hdrs[viapos].vals.len() == 0 {
                    msg.hdrs.remove(viapos);
                }
            }
        }
        // 続く
```

新たに先頭になったvia-parmを解析していきます。
Viaヘッダはリクエストを送信する時に自分自身がSIPメッセージを受け取ることができるアドレスとポートの情報を（すでにViaヘッダがある場合は既存のViaの前に）書くことになっていて、リクエストからレスポンスを生成する時にはViaヘッダを丸ごとコピーすることになっているので、先ほどの先頭のViaを削除したことにより、このレスポンスを送るべき宛先がわかるようになっています。

via-parmのフォーマットはこんな感じ。

```
via-parm          =  sent-protocol LWS sent-by *( SEMI via-params )
sent-by           =  host [ COLON port ]
via-params        =  via-ttl / via-maddr
                     / via-received / via-branch
                     / via-extension
via-ttl           =  "ttl" EQUAL ttl
via-maddr         =  "maddr" EQUAL host
via-received      =  "received" EQUAL (IPv4address / IPv6address)
via-branch        =  "branch" EQUAL token
via-extension     =  generic-param
generic-param  =  token [ EQUAL gen-value ]
gen-value      =  token / host / quoted-string
quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
quoted-pair  =  "\" (%x00-09 / %x0B-0C / %x0E-7F)
COMMA   =  SWS "," SWS ; comma
DQUOTE         =  %x22 ; " (Double Quote)
```


この中からこのレスポンスの宛先を取り出します。
[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 146にこんなことが書いてあります。

```
      o  Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter, using the port indicated
         in the "sent-by" value, or using port 5060 if none is specified
         explicitly. 
```

具体的には、まずIPアドレスはvia-receivedがある場合はそこに書かれたアドレスとsent-byに書かれたポート番号、sent-byにポートが書いていない場合はSIPのデフォルトのポート番号である5060になる。

また[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 147にその続きが書いてあり、

```
      o  Otherwise, if it is not receiver-tagged, the response MUST be
         sent to the address indicated by the "sent-by" value, using the
         procedures in Section 5 of [4].
```

receivedパラメータがない場合はsent-byに書かれているアドレス＆ポートが宛先になります。（rportというパラメータを定義した[拡張](https://www.rfc-editor.org/rfc/rfc3581.txt)もありますがsotafugy8は対応しないことにします。）

via-parmの実例として冒頭に記したシーケンスのF9のメッセージから取り出すと、こんなやつです。

```
SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
 ;received=192.0.2.2
```

さきほどのBNFをみると、`via-params`の部分を構成する`via-ttl`、`via-maddr`、`via-received`、`via-branch`、`via-extension`はいずれも`generic-param`で表現できそうです。generic-paramという名前だけあって他の場所でも使えるかもしれないので、viaとは独立して、複数のgeneric-paramsの値を管理するための構造体を作ることにします。解析するメソッド、指定された名前のパラメータの値を取り出すメソッド、指定された名前のパラメータの値を設定するメソッド、文字列化するメソッドもつくっておきます。

```rust
lazy_static! {
    static ref RE_PRMS: Regex =
        Regex::new(r#"^;\s*(?<name>[^\s=;]+)\s*(=\s*(?<value>([^\s";]+|"([^"]|(\"))*")))?\s*"#)
            .expect("faield to build Regex for PRMS");
}

struct GenericParams {
    elms: Vec<(String, Option<String>)>,
}

impl std::fmt::Display for GenericParams {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        let mut s = "".to_string();
        for prm in self.elms.iter() {
            if let Some(v) = &prm.1 {
                s.push_str(format!(";{}={}", prm.0, v).as_str());
            } else {
                s.push_str(format!(";{}", prm.0).as_str());
            }
        }
        write!(f, "{}", s)
    }
}

impl GenericParams {
    fn new() -> Self {
        Self { elms: vec![] }
    }

    // 解析
    fn parse(&mut self, src: &str) -> Option<()> {
        self.elms = vec![];
        let mut pos = 0;
        while src[pos..].len() > 0 {
            // 正規表現にマッチさせて値を抽出する
            let caps = RE_PRMS.captures(&src[pos..])?;
            // パラメータ名を抽出
            let name = caps.name("name")?.as_str().to_string();
            // パラメータの値を抽出
            if let Some(value) = caps.name("value") {
                self.elms.push((name, Some(value.as_str().to_string())));
            } else {
                self.elms.push((name, None));
            }
            pos += caps.get(0)?.as_str().len();
        }
        Some(())
    }

    // 取得
    fn get(&self, name: &str) -> Option<String> {
        // 値がない要素がある場合と、その名前の要素がない場合の区別がつかない問題あり
        // ただsotafugyでは前者を使うことがないので今は気にしない
        for elm in self.elms.iter() {
            if elm.0 == name {
                return elm.1.clone();
            }
        }
        None
    }

    // 設定
    fn set(&mut self, name: &str, value: Option<String>) {
        // 名前がnameのパラメータがあったらvalueで上書き。
        for elm in self.elms.iter_mut() {
            if elm.0 == name {
                elm.1 = value;
                return;
            }
        }
        // 名前がnameのパラメータがなかったら新規挿入
        self.elms.push((name.to_string(), value));
    }
}

```

`via-params`の部分としてこの`GenericParams`を利用する、via-parmを扱う構造体とそのデータを扱うメソッドを作ります。

```rust
lazy_static! {
    static ref RE_VIA: Regex =
        Regex::new(r"^SIP\s*/\s*2\.0\s*/\s*UDP\s+(?<host>[^ \s:;]+)(\s*:\s*(?<port>\d+))")
            .expect("failed to build Regex for VIA");
}

// Viaヘッダの解析＆編集用
struct Via {
    host: String,
    port: u16,
    prms: GenericParams,
}

impl Via {
    fn new() -> Self {
        Self {
            host: "".to_string(),
            port: 5060,
            prms: GenericParams::new(),
        }
    }

    // 解析
    fn parse(&mut self, buf: &str) -> Option<()> {
        let caps = RE_VIA.captures(buf)?;
        // hostを取り出す
        self.host = caps.name("host")?.as_str().to_string();
        // portがあったらその値を取り出し、なければデフォルトの5060を使う
        self.port = 5060;
        if let Some(m) = caps.name("port") {
            match m.as_str().parse::<u16>() {
                Ok(port) => {
                    self.port = port;
                }
                Err(_) => {
                    return None;
                }
            }
        }
        // パラメータ部分を解析
        self.prms.parse(&buf[caps.get(0)?.as_str().len()..])?;
        Some(())
    }

    // レスポンスの宛先とbranchパラメータを取得
    fn get(&self) -> Option<(String, u16, String)> {
        // 一旦hostを宛先アドレスとして、
        let mut host = self.host.to_string();
        if let Some(r) = self.prms.get("received") {
            // receivedパラメータがある場合はその値で宛先アドレスを上書き
            host = r.to_string();
        }
        // branchパラメータを取り出す
        let mut branch = "".to_string();
        if let Some(b) = self.prms.get("branch") {
            branch = b;
        }
        Some((host, self.port, branch))
    }
}


```

これでレスポンスの宛先を決めることができるようになりました。あとはバイト列に戻して送信するだけです。
先ほどの先頭のviaを削除したメソッドにまず処理を追加します。

```diff_rust
    // レスポンスを処理
    fn proc_response(&self, msg: &mut Message) -> Option<()> {
        // 先頭のViaを取り除く（リクエスト中継時に自分が挿入したViaのはず）
        match msg.search("via", "v") {
            None => {
                return Some(()); // Viaがないレスポンスは中継できないのでおしまい
            }
            Some(viapos) => {
                // 消す
                msg.hdrs[viapos].vals.remove(0);
                // 消した結果、そのヘッダに値がなくなってしまったら、そのヘッダ自体を消す
                if msg.hdrs[viapos].vals.len() == 0 {
                    msg.hdrs.remove(viapos);
                }
            }
        }
-         // 続く        
+         // 新たに先頭になったViaを調べる
+         match msg.search("via", "v") {
+             None => {
+                 return Some(()); // Viaがないレスポンスは中継できないのでおしまい
+             }
+             Some(viapos) => {
+                 let mut via = Via::new();
+                 via.parse(&msg.hdrs[viapos].vals[0])?;
+                 let (host, port, _) = via.get()?;
+                 self.send_message(host, port, &msg.to_string());
+             }
+         }
+         Some(())
+     }
```

そして送信するメソッドはこんな感じです。


```rust
    // 送信
    fn send_message(&self, host: String, port: u16, buf: &str) -> Option<()> {
        // 自分宛の場合は送信しない
        if self.ip == host && self.port == port {
            return None;
        }
        // 送信先アドレスとメッセージの内容を標準出力にはく
        println!(">>>>>>>>>> {}:{} >>>>>", host, port);
        println!("{}", buf);
        // 文字列化しながら送信
        let _ = self
            .sock
            .send_to(buf.as_bytes(), format!("{}:{}", host, port));
        Some(())
    }
```


Messageという構造体で管理しているデータを文字列化する関数も必要です。これはリクエストにも対応しておきます。

```rust
impl std::fmt::Display for Message {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        static CRLF: &str = "\r\n";
        let mut s = String::new();
        for h in self.hdrs.iter() {
            s.push_str(h.to_string().as_str());
        }
        if self.stcode != "" && self.reason != "" {
            // レスポンスの場合
            return write!(
                f,
                "SIP/2.0 {} {}{}{}{}{}",
                self.stcode, self.reason, CRLF, s, CRLF, self.body
            );
        }
        // リクエストの場合
        write!(
            f,
            "{} {} SIP/2.0{}{}{}{}",
            self.method, self.requri, CRLF, s, CRLF, self.body
        )
    }
}
```

この中でHeaderという構造体で管理しているデータも文字列化したいので、この関数も実装しておきます。

```rust
impl std::fmt::Display for Header {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        static CRLF: &str = "\r\n";
        write!(f, "{}: {}{}", self.name, self.vals.join(", "), CRLF)
    }
}
```

これでレスポンスの処理はおしまいです。



# リクエストの処理

Proxyとしてのリクエストの処理は[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 94から始まる「16.3 Request Validation」から「16.6 Request Forwarding」にかけて書いてあり、さらにStatlessの場合はPage 116から始まる「16.11 Stateless Proxy」にも説明があります。また、sotafugy8はregistrarを内包するので、自身宛のREGISTERについては他のリクエストとは異なる処理を実行します。

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のプロキシの説明は実行すべき順に説明が書いてありますが、sotafugy8では実装上の都合から、それとは異なる順序で処理を実行していきます。

## Viaの編集

このリクエストを中継した後に誰かが返送してきたレスポンスが自分自身に届くように、自分のアドレスをViaヘッダに追加します。[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)に記述されている順序とは異なりますが、リクエストの処理中に何らかの理由でレスポンスを生成する可能性があり、その際に先にViaを追加してからレスポンスを生成するようにすれば、そのレスポンスをあたかも受信したレスポンスかのようにみなして先ほど作ったproc_responseメソッドに渡すだけで処理させることができるように真っ先に実行することにしました。

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 145に以下のような記述があります。

```
   When the server transport receives a request over any transport, it
   MUST examine the value of the "sent-by" parameter in the top Via
   header field value.  If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.
```

sent-byのhost部がドメイン名になっていたり送信元IPアドレスが異なっていた場合にはreceivedパラメータを追加してね、と言っています。sotafugy8はhost部が何であろうと無条件にreceivedパラメータを追加することにします。
先ほどレスポンスを処理する際にViaヘッダを取り扱う処理を実装しているので、これを使って解析、receivedパラメータを追加してから文字列に戻します。

まず文字列化する関数を作っておきます

```rust
impl std::fmt::Display for Via {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(
            f,
            "SIP/2.0/UDP {}:{}{}",
            self.host,
            self.port,
            self.prms.to_string()
        )
    }
}
```

そして、viaヘッダを探し、解析し、receivedパラメータを追加し、文字列にして戻す処理を作ります

```rust
    // Top-Viaからbranchを取り出しつつreceivedを追加。branchのハッシュを計算して新たに自アドレスをTopViaとして挿入
    fn update_via(&self, msg: &mut Message, saddr: &SocketAddr) -> Option<()> {
        // viaヘッダを解析（ない場合はエラー）
        let viapos = msg.search("via", "v")?;
        let mut via = Via::new();
        via.parse(&msg.hdrs[viapos].vals[0])?;
        // receivedパラメータを追加
        via.prms.set("received", Some(saddr.ip().to_string()));
        msg.hdrs[viapos].vals = vec![via.to_string()];
        // 続く
    }
```

続いて、自身のアドレスを追加します。これによりこのリクエストに対応するレスポンスが自身に戻ってくるようになります。Viaヘッダの値にはbranchというパラメータが必要で、ユニークな値にしなくてはならないのですが、Stateless Proxyは受け取った信号をいじってから送信するだけのものであり、ユニークにするのが難しいので、　[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 116にこんなことが書いてあります。

```
         The stateless proxy MAY use any technique it likes to guarantee
         uniqueness of its branch IDs across transactions.  However, the
         following procedure is RECOMMENDED.  The proxy examines the
         branch ID in the topmost Via header field of the received
         request.  If it begins with the magic cookie, the first
         component of the branch ID of the outgoing request is computed
         as a hash of the received branch ID.
```

このように、受信したメッセージの先頭のViaにあるbranchパラメータを取り出して、そのハッシュを計算して使うことを推奨されています。（```If it begins with the magic cookie,```というのは、RFC3261準拠なら、といっているのと同義で、sotafugy8は通信相手がRFC3261準拠であることを前提にしているのでこの方法で良いということになります）
従って、まずは受け取ったリクエストの先頭のViaからbranchパラメータの値を取り出したい、ということになります。実はサラッと流して誤魔化しましたが、このbranchパラメータの値を取り出す処理はレスポンスを処理する際にその宛先を判定するために作ったメソッドで取得できるようにしておきました。

先ほどのupdate_viaというメソッドの続きを実装します。

```diff_rust
    // Top-Viaからbranchを取り出しつつreceivedを追加。branchのハッシュを計算して新たに自アドレスをTopViaとして挿入
    fn update_via(&self, msg: &mut Message, saddr: &SocketAddr) -> Option<()> {
        // viaヘッダを解析（ない場合はエラー）
        let viapos = msg.search("via", "v")?;
        let mut via = Via::new();
        via.parse(&msg.hdrs[viapos].vals[0])?;
        // receivedパラメータを追加
        via.prms.set("received", Some(saddr.ip().to_string()));
        msg.hdrs[viapos].vals = vec![via.to_string()];
-         // 続く        
+         // 自分のアドレスを追加する上で必要な情報（branch）を取得
+         let (_, _, mut branch) = via.get()?;
+         // 自身の情報をViaヘッダの先頭に追加
+         branch = format!("{:x}", md5::compute(format!("xxx{}", branch).as_bytes()));
+         let tmp = format!(
+             "SIP/2.0/UDP {}:{};branch=z9hG4bK{}",
+             self.ip, self.port, branch
+         );
+         msg.hdrs[viapos].vals.insert(0, tmp);
+         Some(())
    }
```

## Proxy-Requireヘッダの処理

Proxyに何らかの拡張への対応を求める場合に、Proxy-Requireというヘッダにその拡張の名前が列挙されたリクエストが送られてくる場合があります。[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 95から96にかけてこんな感じで書いてあります。

```
   5. Proxy-Require check

      Future extensions to this protocol may introduce features that
      require special handling by proxies.  Endpoints will include a
      Proxy-Require header field in requests that use these features,
      telling the proxy not to process the request unless the feature is
      understood.
      If the request contains a Proxy-Require header field (Section
      20.29) with one or more option-tags this element does not
      understand, the element MUST return a 420 (Bad Extension)
      response.  The response MUST include an Unsupported (Section
      20.40) header field listing those option-tags the element did not
      understand.
```

sotafugy8は拡張の類には対応しないことにしたので、上記の通り、420エラーレスポンスを返すことにします。

まずMessageという構造体にリクエストからレスポンスを生成するメソッドを実装します。
[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 50に以下のような説明があります。

```
8.2.6.2 Headers and Tags

   The From field of the response MUST equal the From header field of
   the request.  The Call-ID header field of the response MUST equal the
   Call-ID header field of the request.  The CSeq header field of the
   response MUST equal the CSeq field of the request.  The Via header
   field values in the response MUST equal the Via header field values
   in the request and MUST maintain the same ordering.

   If a request contained a To tag in the request, the To header field
   in the response MUST equal that of the request.  However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present).  This serves to identify the UAS that is
   responding, possibly resulting in a component of a dialog ID.  The
   same tag MUST be used for all responses to that request, both final
   and provisional (again excepting the 100 (Trying)).  Procedures for
   the generation of tags are defined in Section 19.3.
```

From、Call-ID、CSeq、Viaはコピー。Toヘッダはtagがある場合はコピー、無い場合はtagを生成してToにくっつけてからコピー。Statelessでタグを生成する方法についてはPage 51に

```
      o  To header tags MUST be generated for responses in a stateless
         manner - in a manner that will generate the same tag for the
         same request consistently.  For information on tag construction
         see Section 19.3.
```
と、書いてあります。しかし、Section 19.3を見てみると、、

```
   Besides the requirement for global uniqueness, the algorithm for
   generating a tag is implementation-specific.
```

ということで具体的なことは書いてありませんでした。
他の箇所も含め、tagの具体的な生成方法については見つけることができませんでした。branchの生成方法は具体的な説明があったので、見落としているだけかもしれませんが。。
しょうがないのでsotafugy8ではCall-IDのハッシュを計算してtagに使うことにします。（前段にproxyがいてforkingなどしていたらまずいかもしれませんが、ちょっとよくわかりませんでした。いずれ勉強しておきます。）

```rust
    // この信号（リクエスト）からレスポンスを生成する
    fn gen_resp(&self, stcode: &str, reason: &str) -> Option<Message> {
        if self.method == "ACK" {
            return None;
        }
        let resp_hdrs: Vec<&str> = vec![
            "call-id",
            "i",
            "from",
            "f",
            "to",
            "t",
            "via",
            "v",
            "cseq",
            "record-route",
        ];
        let mut resp = Message::new();
        (resp.stcode, resp.reason) = (stcode.to_string(), reason.to_string());
        for hdr in self.hdrs.iter() {
            if resp_hdrs.contains(&hdr.name.to_lowercase().as_str()) {
                let mut h = Header::new();
                h.set(&hdr.name, &hdr.vals);
                resp.hdrs.push(h);
            }
        }
        let mut content_length = Header::new();
        content_length.set("l", &vec!["0".to_string()]);
        resp.hdrs.push(content_length);
        let topos = resp.search("to", "t")?;
        let mut toaddr = NameAddr::new();
        toaddr.parse(&resp.hdrs[topos].vals[0])?;
        if None == toaddr.prms.get("tag") {
            let cidpos = resp.search("call-id", "i")?;
            let cid = &resp.hdrs[cidpos].vals[0];
            let totag = format!("{:x}", md5::compute(format!("yyy{}", cid).as_bytes()));
            toaddr.prms.set("tag", Some(totag));
        }
        resp.hdrs[topos].vals = vec![toaddr.to_string()];
        Some(resp)
    }
```

この中で使っているNameAddrについては後ほど説明します（先に別の構造体の説明をしたほうがわかりやすいと思うので）。


これを使って、Proxy-Requireヘッダがあったら420レスポンスを返すメソッドを実装します。このときProxy-Requireヘッダに載っていた情報は丸ごとレスポンスのUnsupportedヘッダにコピーします。

```rust
    fn proc_proxy_require(&self, msg: &mut Message) -> Option<()> {
        // proxy-requireヘッダを探して、、
        if let Some(prpos) = msg.search("proxy-require", "") {
            // あったら420レスポンスを生成
            let mut resp = msg.gen_resp("420", "Bad Extension")?;
            // proxy-requireにのっていた文字列をunsupportedにコピー
            let mut unsupported = Header::new();
            unsupported.set("Unsupported", &msg.hdrs[prpos].vals);
            resp.hdrs.push(unsupported);
            self.proc_response(&mut resp);
            return None;
        }
        Some(())
    }
```


## 宛先は自分か？チェック

Request-URIを解析して、このメッセージがこのプロキシの管理下にあるユーザに宛てたものであるかを調べます。
sotafugy8はSIP-URIにしか対応しないので、[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)に書いてあるSIP-URIのフォーマットを以下に示します。

```
SIP-URI          =  "sip:" [ userinfo ] hostport
                    uri-parameters [ headers ]
userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"
user             =  1*( unreserved / escaped / user-unreserved )
user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
password         =  *( unreserved / escaped /
                    "&" / "=" / "+" / "$" / "," )
hostport         =  host [ ":" port ]
host             =  hostname / IPv4address / IPv6reference
hostname         =  *( domainlabel "." ) toplabel [ "." ]
domainlabel      =  alphanum
                    / alphanum *( alphanum / "-" ) alphanum
toplabel         =  ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address    =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
uri-parameters    =  *( ";" uri-parameter)
uri-parameter     =  transport-param / user-param / method-param
                     / ttl-param / maddr-param / lr-param / other-param
transport-param   =  "transport="
                     ( "udp" / "tcp" / "sctp" / "tls"
                     / other-transport)
other-transport   =  token
user-param        =  "user=" ( "phone" / "ip" / other-user)
other-user        =  token
method-param      =  "method=" Method
ttl-param         =  "ttl=" ttl
maddr-param       =  "maddr=" host
lr-param          =  "lr"
other-param       =  pname [ "=" pvalue ]
pname             =  1*paramchar
pvalue            =  1*paramchar
paramchar         =  param-unreserved / unreserved / escaped
param-unreserved  =  "[" / "]" / "/" / ":" / "&" / "+" / "$"

headers         =  "?" header *( "&" header )
header          =  hname "=" hvalue
hname           =  1*( hnv-unreserved / unreserved / escaped )
hvalue          =  *( hnv-unreserved / unreserved / escaped )
hnv-unreserved  =  "[" / "]" / "/" / "?" / ":" / "+" / "$"

      alphanum  =  ALPHA / DIGIT
      unreserved  =  alphanum / mark
      mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                     / "(" / ")"
      escaped     =  "%" HEXDIG HEXDIG

```

ではSIP-URIを解析しデータを保持するための構造体を定義することにします。解析処理については本気でやると面倒なので、またまたざっくりな解析になっています。


```rust
lazy_static! {
    static ref RE_SIPURI: Regex =
        Regex::new(r"^sip:(((?<user>[^:@]+)(:([^@]+))?)@)?(?<host>[^:;]+)(:(?<port>\d+))?")
            .expect("failed to build Regex for SIPURI");
}

struct SIPURI {
    user: String,
    host: String,
    port: u16,
    prms: String, // 中身を解釈しないので丸ごと文字列のまま保持
}

impl std::fmt::Display for SIPURI {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        let s;
        if self.user != "" {
            s = format!("sip:{}@{}:{}", self.user, self.host, self.port);
        } else {
            s = format!("sip:{}:{}", self.host, self.port);
        }
        write!(f, "{}{}", s, self.prms)
    }
}

impl SIPURI {
    fn new() -> Self {
        Self {
            user: "".to_string(),
            host: "".to_string(),
            port: 5060,
            prms: "".to_string(),
        }
    }

    // 解析
    fn parse(&mut self, buf: &str) -> Option<()> {
        let caps = RE_SIPURI.captures(&buf)?;
        if let Some(u) = caps.name("user") {
            self.user = u.as_str().to_string();
        } else {
            self.user = "".to_string();
        }
        self.host = caps.name("host")?.as_str().to_string();
        self.port = 5060; // デフォルトポートは5060
        if let Some(tmp) = caps.name("port") {
            if let Ok(p) = tmp.as_str().to_string().parse::<u16>() {
                self.port = p; // あったら上書き
            } else {
                return None;
            }
        }
        self.prms = buf[caps.get(0)?.len()..].to_string();
        Some(())
    }
}
```

これでRequest-URIを解析してhostとportを取り出す準備が整いました。こんな感じで使います。



```rust
        let mut requri = SIPURI::new();
        requri.parse(&msg.requri)?;
        if requri.host == self.ip && requri.port == self.port {
            // 自分宛だった場合の処理をここにかく
        }
```




## Registrarとしての動作

このあとで中継処理を見ていきますが、そのなかで送信されてきた信号を投げる先を判断する必要が生じますが、クライアントはREGISTERというリクエストをRegistrarに送信してクライアント自身のアドレスを登録します。[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)の1295行目あたりに以下のようにRegistrarが説明されています。

```
      Registrar: A registrar is a server that accepts REGISTER requests
         and places the information it receives in those requests into
         the location service for the domain it handles.
```

より詳細については[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 63から始まる「10.3 Processing REGISTER Requests」に書いてあります。sotafugy8は(proxyとして動作する場合と同様に)そのごく一部のみを実装することにします。具体的には、以下のような感じです。

* REGISTERからToヘッダのuser部と、Contactヘッダの値（複数ある場合はその先頭にある値）を抽出する
* Contactヘッダの値が「*」だった場合は現在保持しているuser部に対応するContact AddressをContactヘッダに載せて応答する
* Contactヘッダの値がcontact-paramだった場合はそのSIP-URIをContact Addressとして扱う

これを実現するにはToとContactを解析する必要があるのでそのフォーマットを見てみます。[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のBNFから関連の箇所を拾い集めてみました。

```
To        =  ( "To" / "t" ) HCOLON ( name-addr
             / addr-spec ) *( SEMI to-param )
to-param  =  tag-param / generic-param
tag-param   =  "tag" EQUAL token

Contact        =  ("Contact" / "m" ) HCOLON
                  ( STAR / (contact-param *(COMMA contact-param)))
contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec      =  SIP-URI / SIPS-URI / absoluteURI
display-name   =  *(token LWS)/ quoted-string

contact-params     =  c-p-q / c-p-expires
                      / contact-extension
c-p-q              =  "q" EQUAL qvalue
c-p-expires        =  "expires" EQUAL delta-seconds
contact-extension  =  generic-param
delta-seconds      =  1*DIGIT

generic-param  =  token [ EQUAL gen-value ]
gen-value      =  token / host / quoted-string
```

ContactがSTARの場合と、Contactに複数のcontact-paramが載りうることを除いては、ToもContactもname-addrにパラメータがくっつく場合があるものであることが分かります。name-addrに含まれるSIP-URIの部分については、Request-URIを解析する際に実装したSIPURIという構造体を利用し、またパラメータ部分はGenericParamsという構造体を使うことにします。

```rust
lazy_static! {
    static ref RE_NAMEADDR: Regex =
        Regex::new(r#"^(([^"<]+|("([^"]|(\"))*")))?\s*<(?<sipuri>[^>]+)>\s*"#)
            .expect("failed to build Regex for NAMEADDR");
}

struct NameAddr {
    display_name: String,
    sipuri: SIPURI,
    prms: GenericParams,
}

impl std::fmt::Display for NameAddr {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        let s: String;
        if self.display_name == "" {
            s = format!("<{}>", self.sipuri);
        } else {
            s = format!("\"{}\" <{}>", self.display_name, self.sipuri);
        }
        write!(f, "{}{}", s, self.prms)
    }
}

impl NameAddr {
    fn new() -> Self {
        Self {
            display_name: "".to_string(),
            sipuri: SIPURI::new(),
            prms: GenericParams::new(),
        }
    }

    fn parse(&mut self, buf: &str) -> Option<()> {
        if let Some(caps) = RE_NAMEADDR.captures(buf) {
            // name-addrの正規表現にマッチした場合
            if let Some(m) = caps.get(1) {
                // display-nameがあった場合
                self.display_name = m.as_str().trim().to_string();
            } else {
                self.display_name = "".to_string();
            }
            self.sipuri.parse(caps.name("sipuri")?.as_str());
            self.prms.parse(&buf[caps.get(0)?.len()..])?;
            return Some(());
        }
        // name-addrの正規表現にマッチしなかった場合
        if let Some(l) = buf.find(";") {
            // セミコロンがあったらそこまでがSIP-URI、それより後ろはパラメータ
            self.sipuri.parse(&buf[..l]);
            self.prms.parse(&buf[l..])?;
            return Some(());
        }
        // セミコロンがないなら全てSIP-URI
        self.sipuri.parse(buf);
        Some(())
    }
}
```

これを使ってRegistrarとしての処理を実装していきます。

```rust
    fn proc_register(&mut self, msg: &Message) -> Option<()> {
        // Toヘッダの値を解析
        let topos = msg.search("to", "t")?;
        let mut to = NameAddr::new();
        to.parse(&msg.hdrs[topos].vals[0])?;
        // Contactヘッダの値を取得
        let mpos = msg.search("contact", "m")?;
        if msg.hdrs[mpos].vals[0] == "*" {
            // 登録されているContactアドレスを取得する
            match self.locs.get(&to.sipuri.user) {
                None => {
                    // いないので404エラーを返す
                    let mut resp = msg.gen_resp("404", "Not Found")?;
                    return self.proc_response(&mut resp);
                }
                Some(addr) => {
                    // 登録されていたので200を生成
                    let mut resp = msg.gen_resp("200", "OK")?;
                    // 登録されていたアドレスをContactヘッダに載せる
                    let mut contact = Header::new();
                    contact.set("m", &vec![addr.to_string()]);
                    resp.hdrs.push(contact);
                    return self.proc_response(&mut resp);
                }
            }
        } else {
            // REGISTERにContactアドレスが載っていたので解析して保存
            let mut addr = NameAddr::new();
            addr.parse(&msg.hdrs[mpos].vals[0])?;
            self.locs.insert(to.sipuri.user, addr.sipuri.to_string());
            // 200レスポンスを生成
            let mut resp = msg.gen_resp("200", "OK")?;
            // Contactアドレスを200レスポンスに載せる
            let mut contact = Header::new();
            contact.set("m", &vec![addr.sipuri.to_string()]);
            resp.hdrs.push(contact);
            self.proc_response(&mut resp);
        }
        None
    }
```

## Request-URIの更新

自分宛だけれどREGISTERではないリクエストについては、Request-URIが指しているユーザをLocation Serviceから探し出してRequest-URIをそのアドレスで書き換えます。Location Serviceに登録されていないユーザの場合は404レスポンスを返します。
こんな感じです。

```rust
        if requri.host == self.ip && requri.port == self.port {
            if msg.method == "REGISTER" {
                return self.proc_register(&msg); // 自身宛のREGISTERはregistrarとして処理
            } else {
                // ユーザを探す
                match self.locs.get(&requri.user) {
                    None => {
                        // 通信相手が見つからなかったので404レスポンスを返す
                        let mut resp = msg.gen_resp("404", "Not Found")?;
                        return self.proc_response(&mut resp);
                    }
                    Some(addr) => {
                        msg.requri = addr.clone();
                    }
                }
            }
        }
```


## Max-Forwardsの減算

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 95にこんなことが書いてあります。

```
   3. Max-Forwards check

      The Max-Forwards header field (Section 20.22) is used to limit the
      number of elements a SIP request can traverse.

      If the request does not contain a Max-Forwards header field, this
      check is passed.

      If the request contains a Max-Forwards header field with a field
      value greater than zero, the check is passed.

      If the request contains a Max-Forwards header field with a field
      value of zero (0), the element MUST NOT forward the request.  If
      the request was for OPTIONS, the element MAY act as the final
      recipient and respond per Section 11.  Otherwise, the element MUST
      return a 483 (Too many hops) response.
```

Max-Forwardsヘッダがあって、もしその値が0だったら483エラーを返します。
さらに[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 100にこんなことが書いてあります。

```
      3. Max-Forwards

         If the copy contains a Max-Forwards header field, the proxy
         MUST decrement its value by one (1).

         If the copy does not contain a Max-Forwards header field, the
         proxy MUST add one with a field value, which SHOULD be 70.

         Some existing UAs will not provide a Max-Forwards header field
         in a request.
```

Max-Forwardsヘッダの値を１減らす、なかったらその値が70であるものとみなす、ということです。

これを実施するメソッドを実装してみます。

```rust
    fn update_max_forwards(&self, msg: &mut Message) -> Option<()> {
        // max-forwardsヘッダを探す
        match msg.search("max-forwards", "") {
            None => {
                // Max-Forwardsヘッダがない場合は70を設定しておしまい
                let mut mf = Header::new();
                mf.set("Max-Forwards", &vec!["70".to_string()]);
                msg.hdrs.push(mf);
            }
            Some(mfpos) => {
                // Max-Forwardsヘッダがあった場合、、
                if let Ok(n) = msg.hdrs[mfpos].vals[0].parse::<u16>() {
                    if n <= 0 {
                        // 0だったら420エラーを返す
                        let mut resp = msg.gen_resp("420", "Too Many Hops")?;
                        self.proc_response(&mut resp);
                        return None;
                    }
                    // 1以上だったら1減算する
                    msg.hdrs[mfpos].vals = vec![(n - 1).to_string()];
                }
            }
        }
        Some(())
    }
```

### Routeの処理

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 97に以下の記載があります。

```
   If the first value in the Route header field indicates this proxy,
   the proxy MUST remove that value from the request.
```

この前に、Request-URIが以前Record-Routeに挿入した値だった場合などの説明がありますが、sotafugy8はいずれも該当しないのでこれだけです。

アドレス解析処理をすでに実装してあるので簡単です。

```rust
    fn update_route(&self, msg: &mut Message) -> Option<()> {
        // routeヘッダを探す
        if let Some(rpos) = msg.search("route", "") {
            // 先頭のアドレスを解析
            let mut addr = NameAddr::new();
            addr.parse(&msg.hdrs[rpos].vals[0])?;
            // 自身のアドレスと比較
            if self.ip == addr.sipuri.host && self.port == addr.sipuri.port {
                // 一致していたら削除
                msg.pop("route", "");
            }
        }
        Some(())
    }
```

### 中継先の決定

[RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)のPage 104に「7. Determine Next-Hop Address, Port, and Transport」というアイテムがあり、リクエストの送信先を決める方法が説明されています。sotafugy8はその説明のほとんどが当てはまらず、この記述に従えばよさそうです。

```
                                                 the proxy MUST apply
         the procedures to the first value in the Route header field, if
         present, else the Request-URI.
```
Routeヘッダがあればその先頭のアドレス、なければRequest-URIが示すアドレスを中継先t

```rust
    fn get_target(&self, msg: &mut Message) -> Option<(String, u16)> {
        // routeヘッダがある場合はその先頭のアドレスが宛先
        if let Some(rpos) = msg.search("route", "") {
            let mut addr = NameAddr::new();
            addr.parse(&msg.hdrs[rpos].vals[0])?;
            return Some((addr.sipuri.host, addr.sipuri.port));
        }
        // routeヘッダがない場合はrequest-uriが宛先
        let mut target = SIPURI::new();
        target.parse(&msg.requri)?;
        Some((target.host, target.port))
    }
```

### 送信

編集が終わり宛先も決まったので送信します。送信する処理はレスポンスの送信の時にリクエストへの対応もしてあるので、そのメソッドを呼ぶだけです。

ここまでに実装した関数も含めて呼び出してリクエストの処理を完成させます。

```rust
    fn proc_request(&mut self, msg: &mut Message, saddr: &SocketAddr) -> Option<()> {
        self.update_via(msg, &saddr)?;
        self.proc_proxy_require(msg)?;
        let mut requri = SIPURI::new();
        requri.parse(&msg.requri)?;
        if requri.host == self.ip && requri.port == self.port {
            if msg.method == "REGISTER" {
                return self.proc_register(&msg); // 自身宛のREGISTERはregistrarとして処理
            } else {
                // ユーザを探す
                match self.locs.get(&requri.user) {
                    None => {
                        // 通信相手が見つからなかったので404レスポンスを返す
                        let mut resp = msg.gen_resp("404", "Not Found")?;
                        return self.proc_response(&mut resp);
                    }
                    Some(addr) => {
                        msg.requri = addr.clone();
                    }
                }
            }
        }
        self.update_max_forwards(msg)?;
        self.update_route(msg)?;
        let (host, port) = self.get_target(msg)?;
        return self.send_message(host, port, &msg.to_string());
    }
```

# 起動

起動パラメータを使ってbindするIPアドレスとポートを受けとるようにします。IPアドレスはこのsotafugy8が管理するドメインとしても使用します。

```rust
fn main() {
    let args: Vec<String> = env::args().collect();
    if args.len() >=3 {
        if let Ok(port) = args[2].parse::<u16>() {
            let mut px = Proxy::new(&args[1], port);
            px.run();
        }
    }
}
```

これで完成です。

AppStoreでSIPフォンを探して手持ちのiPhoneとiPadの双方にインストール、動かしてみたら、無事通話できました。よかった。

# まとめ


SIPの仕様をどうにか思い出しながら、いろいろ機能を限定しつつ[Rust](https://www.rust-lang.org/)でstateless proxyを実装、適当にみつけたSIPフォン間での通話を成功させることができました。
どうにか動く物は作れましたが、手を抜きまくっているし間違えているところもあるでしょうし、いまもよくわかっていない点も多々ありますので、今後も学習を継続していきたいと思います。
ほぼ私の趣味のプログラミングのトレースでしかない記事となりましたが、どなたかの参考あるいは暇つぶしになれば幸いです。


最後に、今回作ったソースコード全体を記しておきます。クリックすると展開されます。


<details><summary>完成したソースコード</summary><div>


```rust
use lazy_static::lazy_static;
use regex::Regex;
use std::collections::HashMap;
use std::env;
use std::net::SocketAddr;
use std::net::UdpSocket;

fn main() {
    let args: Vec<String> = env::args().collect();
    if args.len() >= 3 {
        if let Ok(port) = args[2].parse::<u16>() {
            let mut px = Proxy::new(&args[1], port);
            px.run();
        }
    }
}

// 各種解析に使っている正規表現たち
lazy_static! {
    static ref RE_SL: Regex = Regex::new(r"^(([^ ]+) ([^ ]+) )?SIP/2\.0( (\d\d\d) ([^\r\n]+))?")
        .expect("failed to build Regex for Start-Line");
    static ref RE_HVALUE: Regex = Regex::new(r#"^(([^",]|("([^"]|(\"))*"))+)(\s*,\s*)?"#)
        .expect("failed to build Regex for HVALUE");
    static ref RE_VIA: Regex =
        Regex::new(r"^SIP\s*/\s*2\.0\s*/\s*UDP\s+(?<host>[^ \s:;]+)(\s*:\s*(?<port>\d+))")
            .expect("failed to build Regex for VIA");
    static ref RE_NAMEADDR: Regex =
        Regex::new(r#"^(([^"<]+|("([^"]|(\"))*")))?\s*<(?<sipuri>[^>]+)>\s*"#)
            .expect("failed to build Regex for NAMEADDR");
    static ref RE_SIPURI: Regex =
        Regex::new(r"^sip:(((?<user>[^:@]+)(:([^@]+))?)@)?(?<host>[^:;]+)(:(?<port>\d+))?")
            .expect("failed to build Regex for SIPURI");
    static ref RE_PRMS: Regex =
        Regex::new(r#"^;\s*(?<name>[^\s=;]+)\s*(=\s*(?<value>([^\s";]+|"([^"]|(\"))*")))?\s*"#)
            .expect("faield to build Regex for PRMS");
}

// プロキシ
struct Proxy {
    ip: String,
    port: u16,
    sock: UdpSocket,
    locs: HashMap<String, String>,
}

impl Proxy {
    fn new(ip: &str, port: u16) -> Self {
        let hostport = format!("{}:{}", ip, port);
        Self {
            ip: String::from(ip),
            port: port,
            sock: UdpSocket::bind(hostport).unwrap(),
            locs: HashMap::new(),
        }
    }

    fn run(&mut self) {
        let mut counter = 0;
        let mut buf = [0; 0xffff];
        loop {
            if let Ok((rsize, saddr)) = self.sock.recv_from(&mut buf) {
                if let Ok(s) = std::str::from_utf8(&buf[..rsize]) {
                    self.proc(s, saddr);
                    counter += 1;
                    println!("{}", counter);
                }
            }
        }
    }

    fn proc(&mut self, s: &str, saddr: SocketAddr) -> Option<()> {
        println!(">>> {} >>>>>>>>\r\n{}", saddr.to_string(), s);
        let mut msg = Message::new();
        if let Some(_) = msg.parse(s) {
            if msg.method != "" && msg.requri != "" {
                self.proc_request(&mut msg, &saddr);
            } else if msg.stcode != "" && msg.reason != "" {
                self.proc_response(&mut msg);
            }
        }
        Some(())
    }

    // リクエストの処理
    fn proc_request(&mut self, msg: &mut Message, saddr: &SocketAddr) -> Option<()> {
        self.update_via(msg, &saddr)?;
        self.proc_proxy_require(msg)?;
        let mut requri = SIPURI::new();
        requri.parse(&msg.requri)?;
        if requri.host == self.ip && requri.port == self.port {
            if msg.method == "REGISTER" {
                return self.proc_register(&msg); // 自身宛のREGISTERはregistrarとして処理
            } else {
                // ユーザを探す
                match self.locs.get(&requri.user) {
                    None => {
                        // 通信相手が見つからなかったので404レスポンスを返す
                        let mut resp = msg.gen_resp("404", "Not Found")?;
                        return self.proc_response(&mut resp);
                    }
                    Some(addr) => {
                        msg.requri = addr.clone();
                    }
                }
            }
        }
        self.update_max_forwards(msg)?;
        self.update_route(msg)?;
        let (host, port) = self.get_target(msg)?;
        return self.send_message(host, port, &msg.to_string());
    }

    // Proxy-Requireが載っていたら420レスポンスを返す
    fn proc_proxy_require(&self, msg: &mut Message) -> Option<()> {
        // proxy-requireヘッダを探して、、
        if let Some(prpos) = msg.search("proxy-require", "") {
            // あったら420レスポンスを生成
            let mut resp = msg.gen_resp("420", "Bad Extension")?;
            // proxy-requireにのっていた文字列をunsupportedにコピー
            let mut unsupported = Header::new();
            unsupported.set("Unsupported", &msg.hdrs[prpos].vals);
            resp.hdrs.push(unsupported);
            self.proc_response(&mut resp);
            return None;
        }
        Some(())
    }

    // REGISTRARとしての処理
    fn proc_register(&mut self, msg: &Message) -> Option<()> {
        // Toヘッダの値を解析
        let topos = msg.search("to", "t")?;
        let mut to = NameAddr::new();
        to.parse(&msg.hdrs[topos].vals[0])?;
        // Contactヘッダの値を取得
        let mpos = msg.search("contact", "m")?;
        if msg.hdrs[mpos].vals[0] == "*" {
            // 登録されているContactアドレスを取得する
            match self.locs.get(&to.sipuri.user) {
                None => {
                    // いないので404エラーを返す
                    let mut resp = msg.gen_resp("404", "Not Found")?;
                    return self.proc_response(&mut resp);
                }
                Some(addr) => {
                    // 登録されていたので200を生成
                    let mut resp = msg.gen_resp("200", "OK")?;
                    // 登録されていたアドレスをContactヘッダに載せる
                    let mut contact = Header::new();
                    contact.set("m", &vec![addr.to_string()]);
                    resp.hdrs.push(contact);
                    return self.proc_response(&mut resp);
                }
            }
        } else {
            // REGISTERにContactアドレスが載っていたので解析して保存
            let mut addr = NameAddr::new();
            addr.parse(&msg.hdrs[mpos].vals[0])?;
            self.locs.insert(to.sipuri.user, addr.sipuri.to_string());
            // 200レスポンスを生成
            let mut resp = msg.gen_resp("200", "OK")?;
            // Contactアドレスを200レスポンスに載せる
            let mut contact = Header::new();
            contact.set("m", &vec![addr.sipuri.to_string()]);
            resp.hdrs.push(contact);
            self.proc_response(&mut resp);
        }
        None
    }

    // Max-Forwardsの減算処理
    fn update_max_forwards(&self, msg: &mut Message) -> Option<()> {
        // max-forwardsヘッダを探す
        match msg.search("max-forwards", "") {
            None => {
                // Max-Forwardsヘッダがない場合は70を設定しておしまい
                let mut mf = Header::new();
                mf.set("Max-Forwards", &vec!["70".to_string()]);
                msg.hdrs.push(mf);
            }
            Some(mfpos) => {
                // Max-Forwardsヘッダがあった場合、、
                if let Ok(n) = msg.hdrs[mfpos].vals[0].parse::<u16>() {
                    if n <= 0 {
                        // 0だったら420エラーを返す
                        let mut resp = msg.gen_resp("420", "Too Many Hops")?;
                        self.proc_response(&mut resp);
                        return None;
                    }
                    // 1以上だったら1減算する
                    msg.hdrs[mfpos].vals = vec![(n - 1).to_string()];
                }
            }
        }
        Some(())
    }

    // routeヘッダの更新
    fn update_route(&self, msg: &mut Message) -> Option<()> {
        // routeヘッダを探す
        if let Some(rpos) = msg.search("route", "") {
            // 先頭のアドレスを解析
            let mut addr = NameAddr::new();
            addr.parse(&msg.hdrs[rpos].vals[0])?;
            // 自身のアドレスと比較
            if self.ip == addr.sipuri.host && self.port == addr.sipuri.port {
                // 一致していたら削除
                msg.pop("route", "");
            }
        }
        Some(())
    }

    // リクエストの宛先の決定
    fn get_target(&self, msg: &mut Message) -> Option<(String, u16)> {
        // routeヘッダがある場合はその先頭のアドレスが宛先
        if let Some(rpos) = msg.search("route", "") {
            let mut addr = NameAddr::new();
            addr.parse(&msg.hdrs[rpos].vals[0])?;
            return Some((addr.sipuri.host, addr.sipuri.port));
        }
        // routeヘッダがない場合はrequest-uriが宛先
        let mut target = SIPURI::new();
        target.parse(&msg.requri)?;
        Some((target.host, target.port))
    }

    // レスポンスを処理
    fn proc_response(&self, msg: &mut Message) -> Option<()> {
        // 先頭のViaを取り除く（リクエスト中継時に自分が挿入したViaのはず）
        match msg.search("via", "v") {
            None => {
                return Some(()); // Viaがないレスポンスは中継できないのでおしまい
            }
            Some(viapos) => {
                // 消す
                msg.hdrs[viapos].vals.remove(0);
                // 消した結果、そのヘッダに値がなくなってしまったら、そのヘッダ自体を消す
                if msg.hdrs[viapos].vals.len() == 0 {
                    msg.hdrs.remove(viapos);
                }
            }
        }
        // 新たに先頭になったViaを調べる
        match msg.search("via", "v") {
            None => {
                return Some(()); // Viaがないレスポンスは中継できないのでおしまい
            }
            Some(viapos) => {
                let mut via = Via::new();
                via.parse(&msg.hdrs[viapos].vals[0])?;
                let (host, port, _) = via.get()?;
                self.send_message(host, port, &msg.to_string());
            }
        }
        Some(())
    }

    // 送信
    fn send_message(&self, host: String, port: u16, buf: &str) -> Option<()> {
        // 自分宛の場合は送信しない
        if self.ip == host && self.port == port {
            return None;
        }
        // 送信先アドレスとメッセージの内容を標準出力にはく
        println!(">>>>>>>>>> {}:{} >>>>>", host, port);
        println!("{}", buf);
        // 文字列化しながら送信
        let _ = self
            .sock
            .send_to(buf.as_bytes(), format!("{}:{}", host, port));
        Some(())
    }

    // Top-Viaからbranchを取り出しつつreceivedを追加。branchのハッシュを計算して新たに自アドレスをTopViaとして挿入
    fn update_via(&self, msg: &mut Message, saddr: &SocketAddr) -> Option<()> {
        // viaヘッダを解析（ない場合はエラー）
        let viapos = msg.search("via", "v")?;
        let mut via = Via::new();
        via.parse(&msg.hdrs[viapos].vals[0])?;
        // receivedパラメータを追加
        via.prms.set("received", Some(saddr.ip().to_string()));
        msg.hdrs[viapos].vals = vec![via.to_string()];
        // 自分のアドレスを追加する上で必要な情報（branch）を取得
        let (_, _, mut branch) = via.get()?;
        // 自身の情報をViaヘッダの先頭に追加
        branch = format!("{:x}", md5::compute(format!("xxx{}", branch).as_bytes()));
        let tmp = format!(
            "SIP/2.0/UDP {}:{};branch=z9hG4bK{}",
            self.ip, self.port, branch
        );
        msg.hdrs[viapos].vals.insert(0, tmp);
        Some(())
    }
}

// SIPメッセージ
struct Message {
    method: String,    // start-line(Request-Line)のMethod
    requri: String,    // start-line(Request-Line)のRequest-URI
    stcode: String,    // start-line(Status-Line)のStatus Code
    reason: String,    // start-line(Status-Line)のReason Phrease
    hdrs: Vec<Header>, // message-headers
    body: String,      // message-body
}

impl std::fmt::Display for Message {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        static CRLF: &str = "\r\n";
        let mut s = String::new();
        for h in self.hdrs.iter() {
            s.push_str(h.to_string().as_str());
        }
        if self.stcode != "" && self.reason != "" {
            // レスポンスの場合
            return write!(
                f,
                "SIP/2.0 {} {}{}{}{}{}",
                self.stcode, self.reason, CRLF, s, CRLF, self.body
            );
        }
        // リクエストの場合
        write!(
            f,
            "{} {} SIP/2.0{}{}{}{}",
            self.method, self.requri, CRLF, s, CRLF, self.body
        )
    }
}

impl Message {
    fn new() -> Self {
        Self {
            method: "".to_string(),
            requri: "".to_string(),
            stcode: "".to_string(),
            reason: "".to_string(),
            hdrs: vec![],
            body: "".to_string(),
        }
    }

    // 解析
    fn parse(&mut self, buf: &str) -> Option<()> {
        // 全体を分割
        let (sl, hdrs, body) = Self::split(&buf)?;
        // Start-Lineの解析
        self.parse_start_line(sl)?;
        // ヘッダの解析
        for h in hdrs.iter() {
            let mut hdr = Header::new();
            hdr.parse(&h)?;
            self.hdrs.push(hdr);
        }
        // ボディの保持
        self.body = body.to_string();
        Some(())
    }

    // SIPメッセージ全体をstart-line、message-header、bodyへの分割を想定
    fn split(buf: &str) -> Option<(&str, Vec<&str>, &str)> {
        let mut pos = 0;
        let mut margin = 0;
        let mut lines: Vec<&str> = vec![];
        static CRLF: &str = "\r\n";
        loop {
            let tmp = buf[pos+margin..].find(CRLF)?;
            if tmp == 0 {
                // empty-line
                break
            }
            let next_line: &str = &buf[pos+margin+tmp+CRLF.len()..];
            if next_line.starts_with(" ") || next_line.starts_with("\t") {
                margin += tmp + CRLF.len();
            } else {
                lines.push(&buf[pos..pos+margin+tmp]);
                pos += margin + tmp + CRLF.len();
                margin = 0;
            }
        }
        let sl = lines.remove(0); // start-lineを抜き出す
        Some((sl, lines, &buf[pos + 2..])) // 2は"\r\n"の長さ
    }

    // start-lineの解析
    fn parse_start_line(&mut self, buf: &str) -> Option<()> {
        let cap = RE_SL.captures(buf)?;
        if let Some(m) = cap.get(2) {
            // requestの場合
            self.method = m.as_str().to_string();
            self.requri = cap.get(3)?.as_str().to_string();
        } else if let Some(m) = cap.get(5) {
            // responseの場合
            self.stcode = m.as_str().to_string();
            self.reason = cap.get(6)?.as_str().to_string();
        }
        Some(())
    }

    // 指定されたヘッダを探して配列の何番目かを返す。ヘッダ名は小文字で渡すこと。
    fn search(&self, hname1: &str, hname2: &str) -> Option<usize> {
        for (i, hn) in self.hdrs.iter().enumerate() {
            let hname = hn.name.to_lowercase();
            if hname == hname1 || hname == hname2 {
                return Some(i);
            }
        }
        None // 見つからなかった
    }

    // 指定されたヘッダの先頭の要素を取り除きながら返す
    fn pop(&mut self, hname1: &str, hname2: &str) -> Option<String> {
        let i = self.search(hname1, hname2)?;
        let v = self.hdrs[i].vals[0].clone();
        self.hdrs[i].vals.remove(0);
        if self.hdrs[i].vals.len() == 0 {
            self.hdrs.remove(i);
        }
        return Some(v);
    }

    // この信号（リクエスト）からレスポンスを生成する
    fn gen_resp(&self, stcode: &str, reason: &str) -> Option<Message> {
        if self.method == "ACK" {
            return None;
        }
        let resp_hdrs: Vec<&str> = vec![
            "call-id",
            "i",
            "from",
            "f",
            "to",
            "t",
            "via",
            "v",
            "cseq",
            "record-route",
        ];
        let mut resp = Message::new();
        (resp.stcode, resp.reason) = (stcode.to_string(), reason.to_string());
        for hdr in self.hdrs.iter() {
            if resp_hdrs.contains(&hdr.name.to_lowercase().as_str()) {
                let mut h = Header::new();
                h.set(&hdr.name, &hdr.vals);
                resp.hdrs.push(h);
            }
        }
        let mut content_length = Header::new();
        content_length.set("l", &vec!["0".to_string()]);
        resp.hdrs.push(content_length);
        let topos = resp.search("to", "t")?;
        let mut toaddr = NameAddr::new();
        toaddr.parse(&resp.hdrs[topos].vals[0])?;
        if None == toaddr.prms.get("tag") {
            let cidpos = resp.search("call-id", "i")?;
            let cid = &resp.hdrs[cidpos].vals[0];
            let totag = format!("{:x}", md5::compute(format!("yyy{}", cid).as_bytes()));
            toaddr.prms.set("tag", Some(totag));
        }
        resp.hdrs[topos].vals = vec![toaddr.to_string()];
        Some(resp)
    }
}

// message-headerの解析＆編集用
struct Header {
    name: String,      // header-name
    vals: Vec<String>, // header-value
}

impl std::fmt::Display for Header {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        static CRLF: &str = "\r\n";
        write!(f, "{}: {}{}", self.name, self.vals.join(", "), CRLF)
    }
}

impl Header {
    fn new() -> Self {
        Self {
            name: "".to_string(),
            vals: vec![],
        }
    }

    // 解析する
    fn parse(&mut self, buf: &str) -> Option<()> {
        let (name, value) = Self::split(buf)?;
        self.name = name.to_string();
        if vec!["via", "v", "contact", "m", "route"].contains(&name.to_lowercase().as_str()) {
            self.vals = Self::parse_hvalue(value)?;
        } else {
            self.vals = vec![value.to_string()];
        }
        Some(())
    }

    // header-nameとheader-valueに分割する
    fn split(buf: &str) -> Option<(&str, &str)> {
        let vals: Vec<&str> = buf.splitn(2, ":").collect();
        if vals.len() == 2 {
            return Some((vals[0].trim_end(), vals[1].trim_start()));
        }
        None
    }

    // header-valueをCOMMAで分割して配列にする
    fn parse_hvalue(buf: &str) -> Option<Vec<String>> {
        let mut vals: Vec<String> = vec![];
        let mut pos: usize = 0;
        while buf[pos..].len() > 0 {
            let caps = RE_HVALUE.captures(&buf[pos..])?;
            vals.push(caps.get(1)?.as_str().to_string());
            pos += caps.get(0)?.as_str().len();
        }
        Some(vals)
    }

    // このヘッダの名前と値を設定する
    fn set(&mut self, name: &str, vals: &Vec<String>) {
        self.name = name.to_string();
        self.vals = vec![];
        for val in vals.iter() {
            self.vals.push(val.to_string());
        }
    }
}

// Viaヘッダの解析＆編集用
struct Via {
    host: String,
    port: u16,
    prms: GenericParams,
}

impl std::fmt::Display for Via {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(
            f,
            "SIP/2.0/UDP {}:{}{}",
            self.host,
            self.port,
            self.prms.to_string()
        )
    }
}

impl Via {
    fn new() -> Self {
        Self {
            host: "".to_string(),
            port: 5060,
            prms: GenericParams::new(),
        }
    }

    // 解析
    fn parse(&mut self, buf: &str) -> Option<()> {
        let caps = RE_VIA.captures(buf)?;
        // hostを取り出す
        self.host = caps.name("host")?.as_str().to_string();
        // portがあったらその値を取り出し、なければデフォルトの5060を使う
        self.port = 5060;
        if let Some(m) = caps.name("port") {
            match m.as_str().parse::<u16>() {
                Ok(port) => {
                    self.port = port;
                }
                Err(_) => {
                    return None;
                }
            }
        }
        // パラメータ部分を解析
        self.prms.parse(&buf[caps.get(0)?.as_str().len()..])?;
        Some(())
    }

    // レスポンスの宛先とbranchパラメータを取得
    fn get(&self) -> Option<(String, u16, String)> {
        // 一旦hostを宛先アドレスとして、
        let mut host = self.host.to_string();
        if let Some(r) = self.prms.get("received") {
            // receivedパラメータがある場合はその値で宛先アドレスを上書き
            host = r.to_string();
        }
        // branchパラメータを取り出す
        let mut branch = "".to_string();
        if let Some(b) = self.prms.get("branch") {
            branch = b;
        }
        Some((host, self.port, branch))
    }
}

// ContactヘッダとToヘッダとRouteヘッダの解析＆編集用
struct NameAddr {
    display_name: String,
    sipuri: SIPURI,
    prms: GenericParams,
}

impl std::fmt::Display for NameAddr {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        let s: String;
        if self.display_name == "" {
            s = format!("<{}>", self.sipuri);
        } else {
            s = format!("\"{}\" <{}>", self.display_name, self.sipuri);
        }
        write!(f, "{}{}", s, self.prms)
    }
}

impl NameAddr {
    fn new() -> Self {
        Self {
            display_name: "".to_string(),
            sipuri: SIPURI::new(),
            prms: GenericParams::new(),
        }
    }

    fn parse(&mut self, buf: &str) -> Option<()> {
        if let Some(caps) = RE_NAMEADDR.captures(buf) {
            // name-addrの正規表現にマッチした場合
            if let Some(m) = caps.get(1) {
                // display-nameがあった場合
                self.display_name = m.as_str().trim().to_string();
            } else {
                self.display_name = "".to_string();
            }
            self.sipuri.parse(caps.name("sipuri")?.as_str());
            self.prms.parse(&buf[caps.get(0)?.len()..])?;
            return Some(());
        }
        // name-addrの正規表現にマッチしなかった場合
        if let Some(l) = buf.find(";") {
            // セミコロンがあったらそこまでがSIP-URI、それより後ろはパラメータ
            self.sipuri.parse(&buf[..l]);
            self.prms.parse(&buf[l..])?;
            return Some(());
        }
        // セミコロンがないなら全てSIP-URI
        self.sipuri.parse(buf);
        Some(())
    }
}

// Request-URIとcontact-paramとToヘッダのname-addrとroute-paramで使う
struct SIPURI {
    user: String,
    host: String,
    port: u16,
    prms: String, // 中身を解釈しないので丸ごと文字列のまま保持
}

impl std::fmt::Display for SIPURI {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        let s;
        if self.user != "" {
            s = format!("sip:{}@{}:{}", self.user, self.host, self.port);
        } else {
            s = format!("sip:{}:{}", self.host, self.port);
        }
        write!(f, "{}{}", s, self.prms)
    }
}

impl SIPURI {
    fn new() -> Self {
        Self {
            user: "".to_string(),
            host: "".to_string(),
            port: 5060,
            prms: "".to_string(),
        }
    }

    // 解析
    fn parse(&mut self, buf: &str) -> Option<()> {
        let caps = RE_SIPURI.captures(&buf)?;
        if let Some(u) = caps.name("user") {
            self.user = u.as_str().to_string();
        } else {
            self.user = "".to_string();
        }
        self.host = caps.name("host")?.as_str().to_string();
        self.port = 5060; // デフォルトポートは5060
        if let Some(tmp) = caps.name("port") {
            if let Ok(p) = tmp.as_str().to_string().parse::<u16>() {
                self.port = p; // あったら上書き
            } else {
                return None;
            }
        }
        self.prms = buf[caps.get(0)?.len()..].to_string();
        Some(())
    }
}

// 各種パラメータの管理用
struct GenericParams {
    elms: Vec<(String, Option<String>)>,
}

impl std::fmt::Display for GenericParams {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        let mut s = "".to_string();
        for prm in self.elms.iter() {
            if let Some(v) = &prm.1 {
                s.push_str(format!(";{}={}", prm.0, v).as_str());
            } else {
                s.push_str(format!(";{}", prm.0).as_str());
            }
        }
        write!(f, "{}", s)
    }
}

impl GenericParams {
    fn new() -> Self {
        Self { elms: vec![] }
    }

    // 解析
    fn parse(&mut self, src: &str) -> Option<()> {
        self.elms = vec![];
        let mut pos = 0;
        while src[pos..].len() > 0 {
            // 正規表現にマッチさせて値を抽出する
            let caps = RE_PRMS.captures(&src[pos..])?;
            // パラメータ名を抽出
            let name = caps.name("name")?.as_str().to_string();
            // パラメータの値を抽出
            if let Some(value) = caps.name("value") {
                self.elms.push((name, Some(value.as_str().to_string())));
            } else {
                self.elms.push((name, None));
            }
            pos += caps.get(0)?.as_str().len();
        }
        Some(())
    }

    // 取得
    fn get(&self, name: &str) -> Option<String> {
        // 値がない要素がある場合と、その名前の要素がない場合の区別がつかない問題あり
        // ただsotafugyでは前者を使うことがないので今は気にしない
        for elm in self.elms.iter() {
            if elm.0 == name {
                return elm.1.clone();
            }
        }
        None
    }

    // 設定
    fn set(&mut self, name: &str, value: Option<String>) {
        // 名前がnameのパラメータがあったらvalueで上書き。
        for elm in self.elms.iter_mut() {
            if elm.0 == name {
                elm.1 = value;
                return;
            }
        }
        // 名前がnameのパラメータがなかったら新規挿入
        self.elms.push((name.to_string(), value));
    }
}
```
</div></details>



私はこのソースを基にトランザクションの実装やマルチスレッド化、RDBMS利用などの改造を加えて楽しい年末年始を過ごそうと思います！よいお年を！



# 出典
* [RFC2234](https://www.rfc-editor.org/rfc/rfc2234.txt)： The Internet Society (1997)
* [RFC3261](https://www.rfc-editor.org/rfc/rfc3261.txt)： The Internet Society (2002)
* [RFC3665](https://www.rfc-editor.org/rfc/rfc3665.txt)： The Internet Society (2003)


※ 記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。