voip - SIPBYEメッセージの問題

Question

私はSIPサーバーを作成していますが、電話をかけてVoIP電話に接続しています。問題は、VoIP電話を切ると、携帯電話が転送されないBYEメッセージの転送に問題が発生することです。通話を終了します。

これがSIPメッセージログです（サーバーの電話番号を1234に、携帯電話の電話番号を5678に置き換え、サーバーのIPをxに置き換え、VoIP電話のIPをyに置き換えました）-

Incoming from 174.37.45.134:5060 - 
INVITE sip:1234@174.37.45.134:5060;rinstance=f10c56ae7fb62958 SIP/2.0
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:216.82.224.202;lr;ftag=VPSF506071629460>
Record-Route: <sip:4.79.212.229;lr;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.0
Via: SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.0
Via: SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.823f8e12.0
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK9767.723f8e12.0
Via: SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.0
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032616
f: "Carro Ramon"  <sip:5678@4.68.250.148>;tag=VPSF506071629460
t: <sip:+11234@4.79.212.229:5060>
i: MIAMGC0120091027172219041244@209.244.63.32
CSeq: 1 INVITE
m: <sip:+15678@4.68.250.148:5060;transport=udp;nat=yes>
Max-Forwards: 64
c: application/sdp
Content-Length: 192

v=0
o=- 1256664139 1256664140 IN IP4 209.247.22.135
s=-
c=IN IP4 174.37.45.134
t=0 0
m=audio 55540 RTP/AVP 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=nortpproxy:yes

Outgoing to 174.37.45.134:5060 - 
SIP/2.0 180 Ringing
CSeq: 1 INVITE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
Contact: <sip:+15678@4.68.250.148:5060;transport=udp;nat=yes>
From: "Carro Ramon"  <sip:5678@4.68.250.148>;tag=VPSF506071629460
Max-Forwards: 70
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>, <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>, <sip:216.82.224.202;lr;ftag=VPSF506071629460>, <sip:4.79.212.229;lr;ftag=VPSF506071629460>
To: <sip:+11234@4.79.212.229:5060>;tag=dAmXcBGL
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.0, SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.0, SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.823f8e12.0, SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK9767.723f8e12.0, SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.0, SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032616
Content-Length: 0

Outgoing to 174.37.45.134:5060 - 
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
CSeq: 1 INVITE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
Contact: <sip:+15678@4.68.250.148:5060;transport=udp;nat=yes>
Content-Type: application/sdp
From: "Carro Ramon"  <sip:5678@4.68.250.148>;tag=VPSF506071629460
Max-Forwards: 70
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>, <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>, <sip:216.82.224.202;lr;ftag=VPSF506071629460>, <sip:4.79.212.229;lr;ftag=VPSF506071629460>
To: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.0, SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.0, SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.823f8e12.0, SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK9767.723f8e12.0, SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.0, SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032616
Content-Length: 206

v=0
o=Zoiper_user 0 0 IN IP4 xx.xx.xxx.xx
s=Zoiper_session
c=IN IP4 xx.xx.xxx.xx
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

Incoming from 174.37.45.134:5060 - 
ACK sip:+15678@xx.xx.xxx.xx:5060;transport=udp SIP/2.0
Record-Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>
Record-Route: <sip:216.82.224.202;lr;ftag=VPSF506071629460>
Via: SIP/2.0/UDP 174.37.45.134;branch=z9hG4bK9767.ad406992.2
Via: SIP/2.0/UDP 67.228.177.9;rport=5060;branch=z9hG4bK9767.760c9624.2
Via: SIP/2.0/UDP 216.82.224.202;rport=5060;received=216.82.224.202;branch=z9hG4bK9767.723f8e12.2
Via: SIP/2.0/UDP 4.79.212.229;branch=z9hG4bK9767.e30c5303.2
Via: SIP/2.0/UDP 4.68.250.148:5060;branch=z9hG4bK506071629460-1256581032653
From: "CARRO RAMON    "  <sip:+15678@4.68.250.148;isup-oli=0>;tag=VPSF506071629460
To: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
CSeq: 1 ACK
Contact: <sip:4.68.250.148:5060;transport=udp>
Max-Forwards: 66
Content-Length: 0

Outgoing to yyy.yyy.yy.yyy:1024 - 
INVITE sip:3998@192.168.1.121 SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
CSeq: 1 INVITE
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
Contact: <sip:5678@xx.xx.xxx.xx>;transport=UDP
Content-Type: application/sdp
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Max-Forwards: 70
To: <sip:3998@xx.xx.xxx.xx>
User-Agent: Zoiper rev.4186
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Content-Length: 206

v=0
o=Zoiper_user 0 0 IN IP4 xx.xx.xxx.xx
s=Zoiper_session
c=IN IP4 xx.xx.xxx.xx
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

Incoming from yyy.yyy.yy.yyy:1024 - 
SIP/2.0 100 Trying
To: <sip:3998@xx.xx.xxx.xx>
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Server: Linksys/SPA941-5.1.8
Content-Length: 0


Incoming from yyy.yyy.yy.yyy:1024 - 
SIP/2.0 180 Ringing
To: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Server: Linksys/SPA941-5.1.8
Content-Length: 0

Incoming from yyy.yyy.yy.yyy:1024 - 
SIP/2.0 200 OK
To: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 1 INVITE
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Contact: "3998" <sip:3998@192.168.1.121:5060>
Server: Linksys/SPA941-5.1.8
Content-Length: 212
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 49591664 49591664 IN IP4 192.168.1.121
s=-
c=IN IP4 192.168.1.121
t=0 0
m=audio 16432 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

Outgoing to yyy.yyy.yy.yyy:1024 - 
ACK sip:3998@192.168.1.121 SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
CSeq: 1 ACK
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
Contact: <sip:5678@xx.xx.xxx.xx>;transport=UDP
From: "(null)" <sip:5678@xx.xx.xxx.xx>;transport=UDP;tag=7b2add35
Max-Forwards: 70
To: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
User-Agent: Zoiper rev.4186
Via: SIP/2.0/UDP xx.xx.xxx.xx:5060
Content-Length: 0

Incoming from yyy.yyy.yy.yyy:1024 - 
BYE sip:5678@xx.xx.xxx.xx SIP/2.0
Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-598f1319
From: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0
To: "(null)" <sip:5678@xx.xx.xxx.xx>;tag=7b2add35
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
CSeq: 101 BYE
Max-Forwards: 70
User-Agent: Linksys/SPA941-5.1.8
Content-Length: 0

Outgoing to 174.37.45.134:5060 - 
BYE sip:5678@4.68.250.148 SIP/2.0
CSeq: 2 BYE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
Contact: <sip:1234@xx.xx.xxx.xx>
From: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
Max-Forwards: 70
Route: <sip:174.37.45.134;lr=on;ftag=VPSF506071629460>, <sip:67.228.177.9;lr=on;ftag=VPSF506071629460>, <sip:216.82.224.202;lr;ftag=VPSF506071629460>
To: "CARRO RAMON    "  <sip:+15678@4.68.250.148;isup-oli=0>;tag=VPSF506071629460
Via: SIP/2.0/UDP 174.37.45.134:5060
Content-Length: 0

Outgoing to yyy.yyy.yy.yyy:1024 - 
SIP/2.0 200 OK
CSeq: 101 BYE
Call-ID: AW6zfKQ8RWl71MipIe4X1WWKfw7xGGR9@chat.seohosting.com
From: <sip:3998@xx.xx.xxx.xx>;tag=53cca4372c533924i0;tag=D1EASwOG
Max-Forwards: 70
To: "(null)" <sip:5678@xx.xx.xxx.xx>;tag=7b2add35
Via: SIP/2.0/UDP 192.168.1.121:5060;branch=z9hG4bK-598f1319

Incoming from 174.37.45.134:5060 - 
SIP/2.0 408 Request Timeout
CSeq: 2 BYE
Call-ID: MIAMGC0120091027172219041244@209.244.63.32
From: <sip:+11234@4.79.212.229:5060>;tag=BYFeP7T1
To: "CARRO RAMON    "  <sip:+15678@4.68.250.148;isup-oli=0>;tag=VPSF506071629460
Via: SIP/2.0/UDP 174.37.45.134:5060;rport=5060;received=xx.xx.xxx.xx
Server: Kamailio (1.5.2-notls (x86_64/linux))
Content-Length: 0
Warning: 392 67.228.177.9:5060 "Noisy feedback tells:  pid=15004 req_src_ip=174.37.45.134 req_src_port=5060 in_uri=sip:5678@4.68.250.148 out_uri=sip:5678@4.68.250.148 via_cnt==1092"

score 0 · Accepted Answer

発信レッグが BYE 要求を受け入れるかどうか (受け入れているように見えますが...) と、この要求をどのように処理するかを確認することをお勧めします。本当に必要なのは、174.37.45.134 からの同様のログです。問題は .134 の背後にあるようです (タイムアウトは .134 によって生成されました)。

ところで、一見すると、このようなトラブルに陥る可能性のあるいくつかの基本的な呼処理ルールに違反していることがわかります。発信者の SIP スタックが実際にこれを待機している場合、コール ID が実際には記録されない可能性があります。はい、これはバグのある動作ですが、私たちは現実の世界に住んでいます。標準では、Trying ASAP で応答するように指示されています (ルーティングを行う前でも、コール認証の直後でも - 着信側への発信 INVITE を開始する前に、発信側とのコールセッションを完全に確立しています。これは間違ったロジックです。少なくとも失敗した場合発信元に課金されます。

これをすばやく実行できる場合は、最初にコールセットアップシーケンスを修正することをお勧めします。とにかくこれが必要であり、これにより通話の終了が修正される可能性があります。

INVITE  ->
TRYING  <-
        -> INVITE
        <- TRYING
        <- RINGING
RINGING <-
        <- OK
OK      <-
ACK     ->
        -> ACK

score 0 · Accepted Answer

RFC 3261 では、To フィールドと From フィールドに関連付けられている番号 (URI) は同じままであることが規定されています。NAT が関係する場合、IP は変更される可能性がありますが、番号は一定のままである必要があります。お気付きの場合は、BYE ヘッダーの「To」フィールドと「From」フィールドが入れ替わり、不正な形式のパケットになっています。

score 0 · Accepted Answer

「via_cnt==1092」も非常に疑わしいです。

ところで、ローカル電話 (1234) に招待を送信する前に、外部からの呼び出しを受け入れるという点で、B2BUA を構築しているように見えます。ローカルの電話が別のパラメータを受け入れたり、別のコーデックを受け入れたりした場合、最初の発信者にメディアを直接送信するようにローカルの電話に指示したため、失敗することになります。両方ともメディアをサーバーに送信する必要があり、サーバーは中継します (または必要に応じてトランスコードします)。

それをしたくない場合 (つまり、メディアリレーや可能なトランスコーダーとして機能したくない場合)、INVITE をローカルの電話に転送してから、応答を転送する必要があります。基本的には SIP として機能します。プロキシサーバーであり、SIP B2BUA ではありません。

score 0 · Accepted Answer

RFC 3261 に準拠したい場合は、送信する "Via" ヘッダーにオプションの (!) "branch" パラメータを含めることが義務付けられています。

RFC3261 ss 20.42 を参照してください。

この仕様では、ブランチパラメータがすべてのリクエストに存在することが義務付けられていますが、ヘッダーフィールドの BNF は、それがオプションであることを示しています。これにより、ブランチパラメータを挿入する必要のない RFC 2543 要素との相互運用が可能になります。

voip - SIPBYEメッセージの問題

5 に答える 5

Related

Reference