I have a scenario where user Alice registered with OpenSER with UDP port 5070. Then, I have user Bob sending an invite to Alice via the OpenSER using TCP. Hence, OpenSER is bridging my TCP SIP requests to UDP (and vice versa for the responses).
Here is the sequence:
Alice ----- TCP Invite -----> OpenSER ---------- UDP Invite ------
Alice
Alice responds back with 180 ringing, then 200 Ok.
Upon getting the 200 OK, Bob sends an ACK (to complete the INVITE), followed by an Immediate BYE.
THE TROUBLE IS...... the ACK and the BYE that Bob sends are dropped by OpenSER, and never forwarded onto Alice!!!! I see nothing wrong with the messages. WHat is happening?
sip:~ russdaigle$ sudo tcpdump -i en0 -A -q -s 2000 port 5060 Password: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 2000 bytes
The following shows an sip-invite-bye from mutator using TCP to mjsip (via OPENSER). Everything after the ACK is dropped and not sent on.
Then, is a similar but UDP exchange. In that case, we get a 404 not found in response to the BYE!!!
01:17:59.553909 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 588 INVITE sip:alice@siptest2.com:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Contact: sip:bob@10.10.2.6;transport=TCP Max-Forwards: 70 Content-Type: application/sdp Content-Length: 195
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 10.10.2.6 t=0 0 m=audio 5000 RTP/AVP 0 4 97 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000/1 a=rtpmap:97 telephone-event/8000
01:17:59.554929 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 536 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Server: OpenSer (1.1.0-notls (i386/darwin)) Content-Length: 0 Warning: 392 10.10.1.234:5060 "Noisy feedback tells: pid=11962 req_src_ip=10.10.2.6 req_src_port=50135 in_uri=sip:alice@siptest2.com: 5060 out_uri=sip:alice@10.10.2.6:5070 via_cnt==1"
01:17:59.555035 IP 10.10.1.234.sip > 10.10.2.6.5070: UDP, length 814 INVITE sip:alice@10.10.2.6:5070 SIP/2.0 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Contact: sip:bob@10.10.2.6;transport=TCP Max-Forwards: 69 Content-Type: application/sdp Content-Length: 195 P-hint: usrloc applied
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 10.10.2.6 t=0 0 m=audio 5000 RTP/AVP 0 4 97 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000/1 a=rtpmap:97 telephone-event/8000
01:17:59.667962 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 364 SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0
01:17:59.699680 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 505 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0
01:17:59.699683 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 728 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
01:17:59.700273 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 440 SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0
01:17:59.700299 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 663 SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
01:17:59.804566 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 435 ACK sip:alice@siptest2.com:5060 SIP/2.0 Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK59972 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 CSeq: 1 ACK Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Max-Forwards: 70
01:17:59.839493 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 435 BYE sip:alice@siptest2.com:5060 SIP/2.0 Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK68444 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 CSeq: 2 BYE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Max-Forwards: 70
01:18:00.199306 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 728 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Hi!
The client which uses TCP is broken. The ACK and BYE are in-dialog requests and MUST contain the callees Contact: URI as request URI. That means:
ACK sip:alice@192.168.0.3:5070 SIP/2.0 instead of ACK sip:alice@siptest2.com:5060 SIP/2.0
regards klaus
Russ Daigle wrote:
I have a scenario where user Alice registered with OpenSER with UDP port 5070. Then, I have user Bob sending an invite to Alice via the OpenSER using TCP. Hence, OpenSER is bridging my TCP SIP requests to UDP (and vice versa for the responses).
Here is the sequence:
Alice ----- TCP Invite -----> OpenSER ---------- UDP Invite ------> Alice
Alice responds back with 180 ringing, then 200 Ok.
Upon getting the 200 OK, Bob sends an ACK (to complete the INVITE), followed by an Immediate BYE.
THE TROUBLE IS...... the ACK and the BYE that Bob sends are dropped by OpenSER, and never forwarded onto Alice!!!! I see nothing wrong with the messages. WHat is happening?
sip:~ russdaigle$ sudo tcpdump -i en0 -A -q -s 2000 port 5060 Password: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 2000 bytes
The following shows an sip-invite-bye from mutator using TCP to mjsip (via OPENSER). Everything after the ACK is dropped and not sent on.
Then, is a similar but UDP exchange. In that case, we get a 404 not found in response to the BYE!!!
01:17:59.553909 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 588 INVITE sip:alice@siptest2.com:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Contact: sip:bob@10.10.2.6;transport=TCP Max-Forwards: 70 Content-Type: application/sdp Content-Length: 195
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 10.10.2.6 t=0 0 m=audio 5000 RTP/AVP 0 4 97 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000/1 a=rtpmap:97 telephone-event/8000
01:17:59.554929 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 536 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Server: OpenSer (1.1.0-notls (i386/darwin)) Content-Length: 0 Warning: 392 10.10.1.234:5060 "Noisy feedback tells: pid=11962 req_src_ip=10.10.2.6 req_src_port=50135 in_uri=sip:alice@siptest2.com:5060 out_uri=sip:alice@10.10.2.6:5070 via_cnt==1"
01:17:59.555035 IP 10.10.1.234.sip > 10.10.2.6.5070: UDP, length 814 INVITE sip:alice@10.10.2.6:5070 SIP/2.0 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Contact: sip:bob@10.10.2.6;transport=TCP Max-Forwards: 69 Content-Type: application/sdp Content-Length: 195 P-hint: usrloc applied
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 10.10.2.6 t=0 0 m=audio 5000 RTP/AVP 0 4 97 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000/1 a=rtpmap:97 telephone-event/8000
01:17:59.667962 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 364 SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0
01:17:59.699680 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 505 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0
01:17:59.699683 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 728 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
01:17:59.700273 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 440 SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0
01:17:59.700299 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 663 SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
01:17:59.804566 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 435 ACK sip:alice@siptest2.com:5060 SIP/2.0 Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK59972 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 CSeq: 1 ACK Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Max-Forwards: 70
01:17:59.839493 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 435 BYE sip:alice@siptest2.com:5060 SIP/2.0 Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK68444 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 CSeq: 2 BYE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Max-Forwards: 70
01:18:00.199306 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 728 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp
v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
Thanks for the insightful response.
Is that truly a MUST in the RFC definition of the word? (I couldn't find the sections in the RFC that you alluded to.)
I see other call flows in the basic call flows RFC does as you mention. My concern is that stateless or transaction stateful proxies may not now how to forward the "alice@192.168.0.3:5070" request; in fact, it is likely they won't!
I presume my client should only do as you mention if the client is going to contact the other endpoint directly for the rest of the dialog (rather than going through the proxy)? Sending a message to the proxy where request-URI mentioned an IP address the proxy doesn't know is bad, and furthermore specifying a port in the request-URI that is not the same as the port for proxy is listening on also sounds bad.
Especially remember in this case there was a record-route: forcing to continue going through the proxy!!!! Therefore, I would think that changing the request-URI could cause problems with the proxy.
If the record-route headers were not present (other cases I'm testing), would it be permissible for me to continue going though the proxy anyways rather than reverting to sending directly to the endpoint for the remainder of the dialog????
Regards and Thanks!!!
-Russ
On Nov 10, 2006, at 3:11 AM, Klaus Darilion wrote:
Hi!
The client which uses TCP is broken. The ACK and BYE are in-dialog requests and MUST contain the callees Contact: URI as request URI. That means:
ACK sip:alice@192.168.0.3:5070 SIP/2.0 instead of ACK sip:alice@siptest2.com:5060 SIP/2.0
regards klaus
Russ Daigle wrote:
I have a scenario where user Alice registered with OpenSER with UDP port 5070. Then, I have user Bob sending an invite to Alice via the OpenSER using TCP. Hence, OpenSER is bridging my TCP SIP requests to UDP (and vice versa for the responses). Here is the sequence: Alice ----- TCP Invite -----> OpenSER ---------- UDP Invite ------> Alice Alice responds back with 180 ringing, then 200 Ok. Upon getting the 200 OK, Bob sends an ACK (to complete the INVITE), followed by an Immediate BYE. THE TROUBLE IS...... the ACK and the BYE that Bob sends are dropped by OpenSER, and never forwarded onto Alice!!!! I see nothing wrong with the messages. WHat is happening? sip:~ russdaigle$ sudo tcpdump -i en0 -A -q -s 2000 port 5060 Password: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en0, link-type EN10MB (Ethernet), capture size 2000 bytes The following shows an sip-invite-bye from mutator using TCP to mjsip (via OPENSER). Everything after the ACK is dropped and not sent on. Then, is a similar but UDP exchange. In that case, we get a 404 not found in response to the BYE!!! 01:17:59.553909 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 588 INVITE sip:alice@siptest2.com:5060 SIP/2.0 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Contact: sip:bob@10.10.2.6;transport=TCP Max-Forwards: 70 Content-Type: application/sdp Content-Length: 195 v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 10.10.2.6 t=0 0 m=audio 5000 RTP/AVP 0 4 97 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000/1 a=rtpmap:97 telephone-event/8000 01:17:59.554929 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 536 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Server: OpenSer (1.1.0-notls (i386/darwin)) Content-Length: 0 Warning: 392 10.10.1.234:5060 "Noisy feedback tells: pid=11962 req_src_ip=10.10.2.6 req_src_port=50135 in_uri=sip:alice@siptest2.com:5060 out_uri=sip:alice@10.10.2.6:5070 via_cnt==1" 01:17:59.555035 IP 10.10.1.234.sip > 10.10.2.6.5070: UDP, length 814 INVITE sip:alice@10.10.2.6:5070 SIP/2.0 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060 CSeq: 1 INVITE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Contact: sip:bob@10.10.2.6;transport=TCP Max-Forwards: 69 Content-Type: application/sdp Content-Length: 195 P-hint: usrloc applied v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 10.10.2.6 t=0 0 m=audio 5000 RTP/AVP 0 4 97 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000/1 a=rtpmap:97 telephone-event/8000 01:17:59.667962 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 364 SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0 01:17:59.699680 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 505 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0 01:17:59.699683 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 728 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 01:17:59.700273 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 440 SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Server: mjsip stack 1.6 Content-Length: 0 01:17:59.700299 IP 10.10.1.234.sip > 10.10.2.6.50135: tcp 663 SIP/2.0 200 OK Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 01:17:59.804566 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 435 ACK sip:alice@siptest2.com:5060 SIP/2.0 Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK59972 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 CSeq: 1 ACK Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Max-Forwards: 70 01:17:59.839493 IP 10.10.2.6.50135 > 10.10.1.234.sip: tcp 435 BYE sip:alice@siptest2.com:5060 SIP/2.0 Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Route: sip:10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK68444 From: Bob sip:bob@siptest2.com;tag=fromhackblah To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 CSeq: 2 BYE Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com Max-Forwards: 70 01:18:00.199306 IP 10.10.2.6.5070 > 10.10.1.234.sip: UDP, length 728 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.1.234;branch=z9hG4bK9316.e5ab8ce2.0;i=b1 Via: SIP/2.0/TCP 10.10.2.6:50135;branch=z9hG4bK85478043 Record-Route: sip:10.10.1.234;r2=on;lr=on;ftag=fromhackblah Record-Route: <sip: 10.10.1.234;transport=tcp;r2=on;lr=on;ftag=fromhackblah> To: Alice sip:alice@siptest2.com:5060;tag=7c452a3254b2e183 From: Bob sip:bob@siptest2.com;tag=fromhackblah Call-ID: SYRGNUXWKNZNXXPXUAMUTJXXPPMXWKVJFAXUNUUTGG@musecurity.com CSeq: 1 INVITE Contact: sip:alice@192.168.0.3:5070 Server: mjsip stack 1.6 Content-Length: 135 Content-Type: application/sdp v=0 o=- 817933771 817933775 IN IP4 10.10.2.6 s=darkness c=IN IP4 192.168.0.3 t=0 0 m=audio 21000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Klaus Darilion nic.at
Russ Daigle wrote:
Hi Klaus,
Thanks for the insightful response.
Is that truly a MUST in the RFC definition of the word? (I couldn't find the sections in the RFC that you alluded to.)
12.2.1.1 Generating the Request
I see other call flows in the basic call flows RFC does as you mention. My concern is that stateless or transaction stateful proxies may not now how to forward the "alice@192.168.0.3:5070" request; in
it is simple - just forward to 192.168.0.3:5070. Every proxy can do this.
fact, it is likely they won't!
All the information needed for routing is available. the final destination is in the request URI and the intermediate hops are in the Route headers.
I presume my client should only do as you mention if the client is going to contact the other endpoint directly for the rest of the dialog
wrong
(rather than going through the proxy)? Sending a message to the proxy where request-URI mentioned an IP address the proxy doesn't know is bad,
no, it is good. The proxy does not have to lookup the location of the request URI again. It it works also in cases where for example the BYE is routed through other proxies.
and furthermore specifying a port in the request-URI that is not the same as the port for proxy is listening on also sounds bad.
it is the port where the client is listening - the request URI is the final destination. In your scenario, when you insert again the AoR in the request URI, the proxy is unable to forward.
Especially remember in this case there was a record-route: forcing to continue going through the proxy!!!! Therefore, I would think that changing the request-URI could cause problems with the proxy.
My clients do change the request URI and I have no problems in the proxy. Your client does not change the request URI and has problem in the proxy....so guess who is right ;-)
If the record-route headers were not present (other cases I'm testing), would it be permissible for me to continue going though the proxy
you could do and maybe it works, but there is no guarantee as it is not standard conform.
anyways rather than reverting to sending directly to the endpoint for the remainder of the dialog????
regards klaus
-
Klaus Darilion -
Russ Daigle