SIP2SIP

h1. ALGO doorbel

h2. Cannot terminate calls

The unit is not able to correctly terminate the calls when the next hop is a state-full SIP Proxy. A state-full SIP Proxy uses record route to maintain the same signaling path for all subsequent messages part of the same dialog. The unit does not handle this situation, which is standard setup of any VoIP provider that uses a SIP Proxy instead of using a VoIP switch like Asterisk or FreeSwitch, which behave like an end-point. 

Secondly, the unit does not correctly send the BYE to the right next hop when there is more than one SIP server for the same domain (regardless of whether it is a SIP Proxy or not).

The log is below:

2013-01-01T00:41:05+01:00 xs4all phone: sip recv 85.17.186.7:5060, size = 2095

2013-01-01T00:41:05+01:00 xs4all phone: [truncated] INVITE sip:1972@192.168.1.9:5060 SIP/2.0#015#012Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.a08d838>#015#012Record-Route: <sip:81.23.228.129;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.c5809b45>#015#012Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.908d838>#015#012Record-Route: <sip:81.23.228.129;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>#015#012Record-Route: <sip:81.23.228.129;transport=tcp;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.28ff94f5.0#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.338f5a74.0#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.18ff94f5.0#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.238f5a74.0;i=7db2#015#012Via: SIP/2.0/tcp 192.168.1.57:57428;received=82.161.39.123;rport=57428;branch=z9hG4bKPjkhvJ8eoLpQhZKMzod4XgVhJZrJxAEtUe#015#012Max-Forwards: 66#015#012From: "Adrian Georgescu" <sip:ag@ag-projects.c

Expanded messages below for clarity with the relevant headers, notice the Record-Route headers:

<pre>

INVITE sip:1972@192.168.1.9:5060 SIP/2.0

Record-Route: <sip:81.23.228.129;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.c5809b45>

Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.908d838>

Record-Route: <sip:81.23.228.129;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>

Record-Route: <sip:81.23.228.129;transport=tcp;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>

From: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks

To: <sip:1972@ag-projects.com>

Contact: <sip:52138976@82.161.39.123:57428;transport=tcp>

Call-ID: YsTJTTdp5Kxb6eYrxDqViOkl2GaJUCd7

</pre>

2013-01-01T00:41:06+01:00 xs4all phone: sip send 85.17.186.7:5060, size = 1193

2013-01-01T00:41:06+01:00 xs4all phone: [truncated] SIP/2.0 180 Ringing#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.28ff94f5.0#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.338f5a74.0#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.18ff94f5.0#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.238f5a74.0;i=7db2#015#012Via: SIP/2.0/tcp 192.168.1.57:57428;received=82.161.39.123;rport=57428;branch=z9hG4bKPjkhvJ8eoLpQhZKMzod4XgVhJZrJxAEtUe#015#012Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.a08d838>#015#012Record-Route: <sip:81.23.228.129;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.c5809b45>#015#012Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.908d838>#015#012Record-Route: <sip:81.23.228.129;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>#015#012Record-Route: <sip:81.23.228.129;transport=tcp;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>#015#012From: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmk

2013-01-01T00:41:06+01:00 xs4all phone: sip send 85.17.186.7:5060, size = 1421

2013-01-01T00:41:06+01:00 xs4all phone: [truncated] SIP/2.0 200 OK#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.28ff94f5.0#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.338f5a74.0#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.18ff94f5.0#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.238f5a74.0;i=7db2#015#012Via: SIP/2.0/tcp 192.168.1.57:57428;received=82.161.39.123;rport=57428;branch=z9hG4bKPjkhvJ8eoLpQhZKMzod4XgVhJZrJxAEtUe#015#012Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.a08d838>#015#012Record-Route: <sip:81.23.228.129;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.c5809b45>#015#012Record-Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.908d838>#015#012Record-Route: <sip:81.23.228.129;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>#015#012Record-Route: <sip:81.23.228.129;transport=tcp;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>#015#012From: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks#015#012To

2013-01-01T00:41:07+01:00 xs4all phone: sip recv 85.17.186.7:5060, size = 706

2013-01-01T00:41:07+01:00 xs4all phone: ACK sip:1972@82.161.39.123:61031 SIP/2.0#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.18ff94f5.2#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.238f5a74.2#015#012Via: SIP/2.0/UDP 85.17.186.7:5060;branch=z9hG4bK0159.18ff94f5.2#015#012Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bK0159.238f5a74.2;i=7db2#015#012Via: SIP/2.0/tcp 192.168.1.57:57428;received=82.161.39.123;rport=57428;branch=z9hG4bKPj6Uyn5PV6pApqRSblxHYaZ-7P.0Aid2IR#015#012Max-Forwards: 66#015#012From: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks#015#012To: <sip:1972@ag-projects.com>;tag=530668702#015#012Call-ID: YsTJTTdp5Kxb6eYrxDqViOkl2GaJUCd7#015#012CSeq: 31053 ACK#015#012User-Agent: Blink Pro 2.0.3 (MacOSX)#015#012Content-Length:  0#015#012#015

2013-01-01T00:42:05+01:00 xs4all phone: sip send 81.23.228.129:5060, size = 429

2013-01-01T00:42:05+01:00 xs4all phone: BYE sip:52138976@82.161.39.123:57428;transport=tcp SIP/2.0#015#012Via: SIP/2.0/UDP 192.168.1.9:5060;rport;branch=z9hG4bK688014405#015#012From: <sip:1972@ag-projects.com>;tag=530668702#015#012To: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks#015#012Call-ID: YsTJTTdp5Kxb6eYrxDqViOkl2GaJUCd7#015#012CSeq: 27636006 BYE#015#012Allow: INVITE, ACK, CANCEL, BYE, INFO#015#012Max-Forwards: 70#015#012User-Agent: Algo 8028 1.7.8#015#012Content-Length: 0#015#012#015

2013-01-01T00:42:05+01:00 xs4all phone: sip recv 81.23.228.129:5060, size = 495

2013-01-01T00:42:05+01:00 xs4all phone: SIP/2.0 200 OK#015#012Via: SIP/2.0/UDP 192.168.1.9:5060;rport=61031;received=82.161.39.123;branch=z9hG4bK688014405#015#012Record-Route: <sip:81.23.228.129;transport=tcp;lr;r2=on;ftag=530668702>#015#012Record-Route: <sip:81.23.228.129;lr;r2=on;ftag=530668702>#015#012Call-ID: YsTJTTdp5Kxb6eYrxDqViOkl2GaJUCd7#015#012From: <sip:1972@ag-projects.com>;tag=530668702#015#012To: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks#015#012CSeq: 27636006 BYE#015#012Server: Blink Pro 2.0.3 (MacOSX)#015#012Content-Length:  0#015#012#015

h3. Broken BYE

Algo sends this BYE message, which never arrives at the original destination as the intermediate SIP proxy has no information where to route it (it has no Route headers):

<pre>

BYE sip:52138976@82.161.39.123:57428;transport=tcp SIP/2.0

Via: SIP/2.0/UDP 192.168.1.9:5060;rport;branch=z9hG4bK688014405

From: <sip:1972@ag-projects.com>;tag=530668702

To: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks

Call-ID: YsTJTTdp5Kxb6eYrxDqViOkl2GaJUCd7

CSeq: 27636006 BYE

Allow: INVITE, ACK, CANCEL, BYE, INFO

Max-Forwards: 69

User-Agent: Algo 8028 1.7.8

Content-Length: 0

</pre>

h3. Correct BYE

The correct BYE message must be (observe the missing Route headers that the unit must add, they must be copied in reverse order from the original INVITE Record-Route headers same when Algo was building the 200 OK message, which incidentally is done correctly):

<pre>

BYE sip:52138976@82.161.39.123:57428;transport=tcp SIP/2.0

Via: SIP/2.0/UDP 192.168.1.9:5060;rport;branch=z9hG4bK688014405

From: <sip:1972@ag-projects.com>;tag=530668702

Route: <sip:81.23.228.129;transport=tcp;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>

Route: <sip:81.23.228.129;r2=on;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.b5809b45>

Route: <sip:85.17.186.7;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.908d838>

Route: <sip:81.23.228.129;lr;ftag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks;did=1a8.c5809b45>

To: "Adrian Georgescu" <sip:ag@ag-projects.com>;tag=x0VdFW8sEn3bymiNLIQFWpc7Bqe0Hmks

Call-ID: YsTJTTdp5Kxb6eYrxDqViOkl2GaJUCd7

CSeq: 27636006 BYE

Allow: INVITE, ACK, CANCEL, BYE, INFO

Max-Forwards: 69

User-Agent: Algo 8028 1.7.8

Content-Length: 0

</pre>

h2. Incorrect Next Hop

ALGO performs a DNS lookup before sending the BYE. This is plain wrong. The BYE message must be sent to the IP:port where the unit has received the INVITE from and not by performing a new DNS lookup. By doing a DNS lookup one may find another SIP Proxy from the same domain that has no knowledge about the SIP dialog in question, there should never be a DNS lookup performed in the middle of an established SIP dialog, the standard is explicit about this behavior.