heres a debug from quintum, it seems to push the correct Routes, but then the Route statement in the ACK is all wrong,

--- sproto |01/01| 2000/01/01|01:13:16:055 |[syn]:SipMessage::load route list pushing(212.156.5.135) sproto |01/01| 2000/01/01|01:13:16:060 |[syn]:SipMessage::load route list pushing(111.222.333.444) [syn]:AckMessage:: sending to 111.222.333.444:5060 sproto |01/01| 2000/01/01|01:13:16:065 |[syn]:RequestMessage:: encode ACK sip:111.222.333.444;ftag=c3ac7b24-10;lr=on SIP/2.0 CSeq: 1 ACK Call-ID: call-001C293F-56BE-D311-0207-10@10.20.30.40 Contact: sip:046677@10.20.30.40 From: sip:046677@10.20.30.40;tag=c3ac7b24-10 Route: sip:0044123456789@212.156.5.134:5060 Session-GUID: 859321956-892614968-1664628324-878982451 sproto |01/01| 2000/01/01|01:13:16:070 |To: sip:07866318220@111.222.333.444;tag=1A6E0A9C-1BE Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-002e User-Agent: Quintum/1.0.0 Quintum: 0c01030b0233310501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941 Max-Forwards: 70

-------- On 9/8/2005, "Iqbal" iqbal@gigo.co.uk wrote

Hiut if you take a look at the second ACK, the Route statement reads

Route: sip:0044123456789@212.156.5.134:5060.

which is completely wrong , if what you are saying is correct. Is there anyway of swicthing on loose routing, or does anyone know if quintum accepts lr, or lr=on

Iqbal

B

On 9/7/2005, "Bogdan-Andrei Iancu" bogdan@voice-system.ro wrote:

...

Hi Iqbal,

considering 200 OK the Route Set: RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on CT: sip:0044123456789@212.156.5.134:5060

the ACK should be: a)if loose router: RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

the ACK you posted looks like an unsuccessful attempt of a strict routing.

regards, bogdan

Iqbal wrote:

...

Hi

I have a strange looking dialogue, after sending a 200 OK to a quintum box, and get back an ACK, but the Route field seems to be wrong, can someone confirm this.

---

U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@212.156.5.134:5060. Record-Route: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24-a;lr=on.

Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. s=SIP Call. c=IN IP4 212.156.5.134. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 212.156.5.134. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Contact: sip:046677@10.20.30.40. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. Route: sip:0044123456789@212.156.5.134:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.

Max-Forwards: 70.

I thought the Route field should have the data which it pulls from the Record Route headers

tks

iqbal

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi

This makes a little sense :-), according to a), is the path now taken .444 --> .135, if so what does the RURI show.

If the path is that shown by Route headers, then I cannot send it to .134, since that gateway does not respond directly, and will reject the ACK.

Where does the RR, Route headers pick up the info from, I thought that the Route gets it from what is in the RR

Iqbal

On 9/7/2005, "Bogdan-Andrei Iancu" bogdan@voice-system.ro wrote:

Hi Iqbal,

considering 200 OK the Route Set: RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on CT: sip:0044123456789@212.156.5.134:5060

the ACK should be: a)if loose router: RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

the ACK you posted looks like an unsuccessful attempt of a strict routing.

regards, bogdan

Iqbal wrote:

...

Hi

I have a strange looking dialogue, after sending a 200 OK to a quintum box, and get back an ACK, but the Route field seems to be wrong, can someone confirm this.

---

U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@212.156.5.134:5060. Record-Route: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24-a;lr=on.

Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. s=SIP Call. c=IN IP4 212.156.5.134. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 212.156.5.134. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Contact: sip:046677@10.20.30.40. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. Route: sip:0044123456789@212.156.5.134:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.

Max-Forwards: 70.

I thought the Route field should have the data which it pulls from the Record Route headers

tks

iqbal

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi Bogdan

Getting a little clearer :-)

The Contact that ius used is that from the 200 OK which is sent before the ACK (as below), if so that explains where the .134 is coming from.

Also you mentioned that the last hop is taken, but I read somewhere that the topmost route is taken, when forming the route. If it is a strict router, does the RURI pick up the info from the Contact header OR the RR, Also should RURI not read 111.222.333.444 because that what is in the RR in the 200 OK which is sent, which is what the ACK is showing. Whereas in ur example it reads as below

b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

Now if the RURI is as it is in the ACK, the rest should be

Route: sip:0044123456789@212.156.5.135:5060.

I guess at the end of the day whatever it should be, it isn't, anyone know of howto fix it.

Iqbal

Bogdan-Andrei Iancu wrote:

Hi Iqbal,

the Route Set is formed by the all received RR uris and the Contact uri. When doing LR, the last hop from the Route Set in loaded into RURI and all RRs are loaded as Route. The request is not routed by RURI, but by the first Route hdr.

So, if the GW does LR and it generates RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on ,the request will be sent to the first Route (212.156.5.135), which will sent to 111.222.333.444, which will finally use RURI (212.156.5.134) as no other Route is left in request.

regards, bogdan

Iqbal wrote:

...

Hi

This makes a little sense :-), according to a), is the path now taken .444 --> .135, if so what does the RURI show.

If the path is that shown by Route headers, then I cannot send it to .134, since that gateway does not respond directly, and will reject the ACK.

Where does the RR, Route headers pick up the info from, I thought that the Route gets it from what is in the RR

Iqbal

On 9/7/2005, "Bogdan-Andrei Iancu" bogdan@voice-system.ro wrote:

...

Hi Iqbal,

considering 200 OK the Route Set: RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on CT: sip:0044123456789@212.156.5.134:5060

the ACK should be: a)if loose router: RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

the ACK you posted looks like an unsuccessful attempt of a strict routing.

regards, bogdan

Iqbal wrote:

...

Hi

I have a strange looking dialogue, after sending a 200 OK to a quintum box, and get back an ACK, but the Route field seems to be wrong, can someone confirm this.

---

U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@212.156.5.134:5060. Record-Route: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24-a;lr=on.

Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. s=SIP Call. c=IN IP4 212.156.5.134. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 212.156.5.134. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Contact: sip:046677@10.20.30.40. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. Route: sip:0044123456789@212.156.5.134:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.

Max-Forwards: 70.

I thought the Route field should have the data which it pulls from the Record Route headers

tks

iqbal

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

.

Hi Jan

That explains it, but when I debug the quintum logs, it seems to show that it i processing both the routes, and all message exchanges prior to that have been correct. This is giving the symptom of a 10-15 sec call and then a hangup

Iqbal

Jan Janak wrote:

Somehow the value from the first record-route got lost in the user agent. It put the bottom most Route in the request-uri (which is correct becuase the implemenetation is most likely a strict router), it also correctly turned the Contact from 200 OK into Route header field in the ACK, but the Route header field of the proxy (first one in 200 OK) is missing in the ACK.

Jan.

On 08-09-2005 13:12, Iqbal wrote:

...

Hi Bogdan

Getting a little clearer :-)

The Contact that ius used is that from the 200 OK which is sent before the ACK (as below), if so that explains where the .134 is coming from.

Also you mentioned that the last hop is taken, but I read somewhere that the topmost route is taken, when forming the route. If it is a strict router, does the RURI pick up the info from the Contact header OR the RR, Also should RURI not read 111.222.333.444 because that what is in the RR in the 200 OK which is sent, which is what the ACK is showing. Whereas in ur example it reads as below

b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

Now if the RURI is as it is in the ACK, the rest should be

Route: sip:0044123456789@212.156.5.135:5060.

I guess at the end of the day whatever it should be, it isn't, anyone know of howto fix it.

Iqbal

Bogdan-Andrei Iancu wrote:

...

Hi Iqbal,

the Route Set is formed by the all received RR uris and the Contact uri. When doing LR, the last hop from the Route Set in loaded into RURI and all RRs are loaded as Route. The request is not routed by RURI, but by the first Route hdr.

So, if the GW does LR and it generates RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on ,the request will be sent to the first Route (212.156.5.135), which will sent to 111.222.333.444, which will finally use RURI (212.156.5.134) as no other Route is left in request.

regards, bogdan

Iqbal wrote:

...

Hi

This makes a little sense :-), according to a), is the path now taken .444 --> .135, if so what does the RURI show.

If the path is that shown by Route headers, then I cannot send it to .134, since that gateway does not respond directly, and will reject the ACK.

Where does the RR, Route headers pick up the info from, I thought that the Route gets it from what is in the RR

Iqbal

On 9/7/2005, "Bogdan-Andrei Iancu" bogdan@voice-system.ro wrote:

...

Hi Iqbal,

considering 200 OK the Route Set: RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on CT: sip:0044123456789@212.156.5.134:5060

the ACK should be: a)if loose router: RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

the ACK you posted looks like an unsuccessful attempt of a strict routing.

regards, bogdan

Iqbal wrote:

...

Hi

I have a strange looking dialogue, after sending a 200 OK to a quintum box, and get back an ACK, but the Route field seems to be wrong, can someone confirm this.

---

U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@212.156.5.134:5060. Record-Route: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24-a;lr=on.

Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. s=SIP Call. c=IN IP4 212.156.5.134. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 212.156.5.134. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Contact: sip:046677@10.20.30.40. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. Route: sip:0044123456789@212.156.5.134:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.

Max-Forwards: 70.

I thought the Route field should have the data which it pulls from the Record Route headers

tks

iqbal

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

.

---

Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

.

The remote gateways continues to send OK messages, and then eventually the UA sends the BYE, not the remote party.

As for getting the vendir to fix it...anyone have friends in quintum :-)

Iqbal

Jan Janak wrote:

On 08-09-2005 13:48, Iqbal wrote:

...

Hi Jan

That explains it, but when I debug the quintum logs, it seems to show that it i processing both the routes, and all message exchanges prior to that have been correct. This is giving the symptom of a 10-15 sec call and then a hangup

That's because the ACK does not get through and the remote party assumes that the caller is dead and terminates the call. This is correct behavior.

And regarding missing Route header field, if the device does not send it then the only thing that you can do is contact the vendor and ask him to fix it.

Jan.

.

Hi

Just in case I missed something, and before I trash quintum, I have put the entire dialogue below, to make sure I am getting it correct. If someone can take a quick look, cause loose routes and strict are driving me crazy The setup is quintum --- ser---gw (a.b.c.d ----x.x.x.x ----z.z.z.z)

quintum IP = a.b.c.d ser ip = x.x.x.x gw = z.z.z.z gw2 = y.y.y.y

Now you cannot get to gw2 direct

I have read the RFC, and it may as well be written in French. Also the Via headers which messages follow those. From what i see we have

the RURI, The route headers and the via headers, which is followed and when

iqbal

U 2005/09/06 15:23:06.414932 a.b.c.d:5060 -> x.x.x.x:5060 INVITE sip:07866318220@x.x.x.x SIP/2.0. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. Content-Type: application/sdp. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 229. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 70. . v=0. o=Quintum 7 7 IN IP4 a.b.c.d. s=VoipCall. c=IN IP4 a.b.c.d. t=0 0. m=audio 10254 RTP/AVP 18 4 101. c=IN IP4 a.b.c.d. a=rtpmap:18 g729/8000/1. a=rtpmap:4 g723/8000/1. a=rtpmap:101 telephone-event/8000/1.

# U 2005/09/06 15:23:06.452476 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 100 trying -- your call is important to us. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 0. Warning: 392 x.x.x.x:5060 "Noisy feedback tells: pid=24439 req_src_ip=a.b.c.d req_src_port=5060 in_uri=sip:123456789@x.x.x.x out_uri=sip:447866318220@213.166.5.135:5060 via_cnt==1". .

# U 2005/09/06 15:23:06.453034 x.x.x.x:5060 -> z.z.z.z:5060 INVITE sip:44123456789@z.z.z.z:5060 SIP/2.0. Record-Route: sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. Content-Type: application/sdp. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 229. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 16. . v=0. o=Quintum 7 7 IN IP4 a.b.c.d. s=VoipCall. c=IN IP4 a.b.c.d. t=0 0. m=audio 10254 RTP/AVP 18 4 101. c=IN IP4 a.b.c.d. a=rtpmap:18 g729/8000/1. a=rtpmap:4 g723/8000/1. a=rtpmap:101 telephone-event/8000/1.

# U 2005/09/06 15:23:06.465531 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 100 trying -- your call is important to us. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Server: Sip EXpress router (0.8.99-dev (i386/linux)). Content-Length: 0. .

######## U 2005/09/06 15:23:12.785564 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

------------------- This is where the confusion starts, what path should the 183 take, or how is the path decided, is it the RURI, or from the RR, or does it not matter for 183

# U 2005/09/06 15:23:12.788274 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

---------------------- and the OK below, should it not have gone to zzzz and then xxxx, as in RR, and should not the matching RR be stripped off ----------------------

############### U 2005/09/06 15:23:16.610600 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.613003 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 a.b.c.d:5060 -> x.x.x.x:5060 ACK sip:x.x.x.x;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Route: sip:0044123456789@y.y.y.y:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 70. .

# U 2005/09/06 15:23:16.727888 x.x.x.x:5060 -> y.y.y.y:5060 ACK sip:0044123456789@y.y.y.y:5060 SIP/2.0. Record-Route: sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Via: SIP/2.0/UDP x.x.x.x;branch=0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 16. .

Jan Janak wrote:

Somehow the value from the first record-route got lost in the user agent. It put the bottom most Route in the request-uri (which is correct becuase the implemenetation is most likely a strict router), it also correctly turned the Contact from 200 OK into Route header field in the ACK, but the Route header field of the proxy (first one in 200 OK) is missing in the ACK.

Jan.

On 08-09-2005 13:12, Iqbal wrote:

...

Hi Bogdan

Getting a little clearer :-)

The Contact that ius used is that from the 200 OK which is sent before the ACK (as below), if so that explains where the .134 is coming from.

Also you mentioned that the last hop is taken, but I read somewhere that the topmost route is taken, when forming the route. If it is a strict router, does the RURI pick up the info from the Contact header OR the RR, Also should RURI not read 111.222.333.444 because that what is in the RR in the 200 OK which is sent, which is what the ACK is showing. Whereas in ur example it reads as below

b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

Now if the RURI is as it is in the ACK, the rest should be

Route: sip:0044123456789@212.156.5.135:5060.

I guess at the end of the day whatever it should be, it isn't, anyone know of howto fix it.

Iqbal

Bogdan-Andrei Iancu wrote:

...

Hi Iqbal,

the Route Set is formed by the all received RR uris and the Contact uri. When doing LR, the last hop from the Route Set in loaded into RURI and all RRs are loaded as Route. The request is not routed by RURI, but by the first Route hdr.

So, if the GW does LR and it generates RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on ,the request will be sent to the first Route (212.156.5.135), which will sent to 111.222.333.444, which will finally use RURI (212.156.5.134) as no other Route is left in request.

regards, bogdan

Iqbal wrote:

...

Hi

This makes a little sense :-), according to a), is the path now taken .444 --> .135, if so what does the RURI show.

If the path is that shown by Route headers, then I cannot send it to .134, since that gateway does not respond directly, and will reject the ACK.

Where does the RR, Route headers pick up the info from, I thought that the Route gets it from what is in the RR

Iqbal

On 9/7/2005, "Bogdan-Andrei Iancu" bogdan@voice-system.ro wrote:

...

Hi Iqbal,

considering 200 OK the Route Set: RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on CT: sip:0044123456789@212.156.5.134:5060

the ACK should be: a)if loose router: RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

the ACK you posted looks like an unsuccessful attempt of a strict routing.

regards, bogdan

Iqbal wrote:

...

Hi

I have a strange looking dialogue, after sending a 200 OK to a quintum box, and get back an ACK, but the Route field seems to be wrong, can someone confirm this.

---

U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@212.156.5.134:5060. Record-Route: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24-a;lr=on.

Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. s=SIP Call. c=IN IP4 212.156.5.134. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 212.156.5.134. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Contact: sip:046677@10.20.30.40. From: sip:046677@10.20.30.40;tag=c3ac7b24-a. Route: sip:0044123456789@212.156.5.134:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.

Max-Forwards: 70.

I thought the Route field should have the data which it pulls from the Record Route headers

tks

iqbal

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

.

---

Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

.

cheers Jan, that made it clear, except this part

Record-Route header fields tell SIP user agent and proxies where _future_ SIP requests should be sent. Route header field are constructed from Record-Route header fields and they tell user agent and proxies where the request that contains the Route header fields should be sent.

RR tells the UA where future request should go, and Route tells the UA where the request that contains the Route should go...dont follow

Iqbal

Jan Janak wrote:

OK, I think I know where the confusion comes from, it is like this:

When a user agent sends a SIP request, the request will traverse one ore more SIP proxies until it reaches the target user agent. Each proxy and user agent along the path of the request will add its Via header field. The purpose of Via header fields is to make sure that all replies will traverse exactly the same set of proxies (but in reverse order) as the request. In other words Via header fields are used to route _replies_. They record the path of the request so that replies can follow it.

Route and Record-Route header fields have a slightly different purpose -- they are used to route _requests_. Let's assume this scenario:

  INV               INV

UA A --------> proxy ----------> UA B a@1.2.3.4 b@5.6.7.8

User agent A with IP address 1.2.3.4 sends an INVITE request to the proxy which forwards the request to user agent B. UA A adds the Contact header field in the request. The Contact header field tells UA B that it can reach UA A on IP 1.2.3.4. UA B adds a Contact header field to 200 OK reply, telling UA A that it can reach B on IP address 5.6.7.8. This way both user agents exchange their IP addresses and they do not need the proxy anymore. They can easily send all further SIP messages directly to each other, because they remember the IP address of the remote party from Contact header field. This way all further requests would bypass the proxy server.

There are many cases where the proxy server needs to see _all_ future SIP messages exchanged between the user agent (for example when performing accounting). In this case the proxy server needs tell the user agents that they should not exchange future SIP messages directly, but they should relay them through the proxy again.

The proxy server can do this by inserting Record-Route header field in the INVITE message. The Record-Route header field contains the IP address of the proxy and once the INVITE message reaches UA B, it extracts the IP address of the proxy server from Record-Route header field and store it in memory along with the IP address of the remote party (UA A). So UA B knows the IP address of UA A and it also knows that it should send all future requests to UA A through the proxy server.

UA A should also send all future SIP requests to UA B through the proxy server, but it does not know it yet, because the proxy server added Record-Route header field to the INVITE message (which will only reach UA B). UA B has to tell UA A that all future SIP requests should be sent through the proxy, and it does so by copying all Record-Route header fields (in our example there will be only one) from the INVITE message to 200 OK (which is sent from UA B to UA A). UA A will then extract Record-Route header fields along with Contact from 200 OK and store it in memory. At this point both user agents know the IP address of the remote party and that they should relay all SIP messages through the proxy.

Now what happens when UA A wants to send an ACK to UA B. It will lookup the IP address of the remote party (Contact from 200 OK) from memory and put it in the Request-URI of ACK. The reason why ACK does not have the same Request-URI as the original INVITE is that the ACK should be sent to the user agent instance that generated 200 OK -- the Request-URI from the INVITE would fork if user B had several user agents and this is not desirable for ACKs. The URI based on Contact header field never forks, it is delivered only to the UA instance that generated 200 OK. UA A will also find the URI from the Record-Route header field in memory (stored along with the contact of the remote party). It will create a Route header field, put the URI in it and append it to the ACK.

RFC3261 says that if there is a Route header field in a SIP message, then the message should not be sent to the URI in the Request-URI, but to the URI in Route header field and thus the ACK would be sent to the proxy. The proxy will then remove the Route header field and because there is no other Route header field in our message, it will forward the request to the Request-URI which will take the message to UA B.

Note the difference between Record-Route and Route header fields. Record-Route header fields tell SIP user agent and proxies where _future_ SIP requests should be sent. Route header field are constructed from Record-Route header fields and they tell user agent and proxies where the request that contains the Route header fields should be sent. Two header field names are needed to avoid confusion, because a proxy server can add Record-Route header field to _any_ SIP request, including requests that already contain Route header fields (using the same name would mix them).

The relationship between the two user agents (when they remember the IP address of the remote party and IPs of proxies) is called dialog. SIP requests that are forwarded using the information extracted from Contacts and Record-Route header fields are called "SIP requests within dialog" (typically ACK and BYE).

When a user agent sends a SIP request within a dialog, it will always put the Contact of the remote party in the Request-URI and copy all URIs extracted from Record-Route header fields in Route header fields (in either forward or reverse order, based on the direction):

ACK sip:b@5.6.7.8 SIP/2.0 Route: sip:proxy@proxy.ip;lr ...

This is how all recent SIP implementations should behave. Always put the Contact of the remote party into the Request-URI and list all proxies that inserted Record-Route in Route header fields appended to the message. Plain and simple.

Unfortunately there are also older SIP implementations (from pre-RFC3261 era) that need special care, because record-routing worked differently then. In this case the Record-Route does not contain the contact of the remote party but the topmost Route header field, and the value of the remote contact is preserved in the last Route header field in the message. This "compatibility mode" is what makes record routing complex and hard to understand, but you can ignore it (you can always find details in RFC3261).

In conclusion:

1. Via is used to route responses
2. Route and Record-Route headers are used to route requests
3. Proxies use Record-Route to signal that they want to stay on the path

of future requests. 4) User agents use Record-Route headers to build Route headers. 5) Contact of the remote party is always put in the Request-URI of requests in dialogs. 6) The list of Route header field is created from the list of Record-Route header fields. 7) The URI in the topmost Route header field overrides the URI in the Request-URI, so the Request-URI will only be used if there are no more Route header fields.

 Jan.

PS: When talking to Quintum guys, you should ask them to implement what I just described:

1. Take the Contact header field from 200 OK and put it in the Request-URI of ACK.
2. Take all Record-Route header fields from 200 OK, reverse their order, and append them as Route header fields to the ACK.
3. Send the ACK to the topmost Route, if any, otherwise send to the Request-URI.

On 08-09-2005 19:23, Iqbal wrote:

...

Hi

Just in case I missed something, and before I trash quintum, I have put the entire dialogue below, to make sure I am getting it correct. If someone can take a quick look, cause loose routes and strict are driving me crazy The setup is quintum --- ser---gw (a.b.c.d ----x.x.x.x ----z.z.z.z)

quintum IP = a.b.c.d ser ip = x.x.x.x gw = z.z.z.z gw2 = y.y.y.y

Now you cannot get to gw2 direct

I have read the RFC, and it may as well be written in French. Also the Via headers which messages follow those. From what i see we have

the RURI, The route headers and the via headers, which is followed and when

iqbal

U 2005/09/06 15:23:06.414932 a.b.c.d:5060 -> x.x.x.x:5060 INVITE sip:07866318220@x.x.x.x SIP/2.0. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. Content-Type: application/sdp. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 229. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 70. . v=0. o=Quintum 7 7 IN IP4 a.b.c.d. s=VoipCall. c=IN IP4 a.b.c.d. t=0 0. m=audio 10254 RTP/AVP 18 4 101. c=IN IP4 a.b.c.d. a=rtpmap:18 g729/8000/1. a=rtpmap:4 g723/8000/1. a=rtpmap:101 telephone-event/8000/1.

# U 2005/09/06 15:23:06.452476 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 100 trying -- your call is important to us. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 0. Warning: 392 x.x.x.x:5060 "Noisy feedback tells: pid=24439 req_src_ip=a.b.c.d req_src_port=5060 in_uri=sip:123456789@x.x.x.x out_uri=sip:447866318220@213.166.5.135:5060 via_cnt==1". .

# U 2005/09/06 15:23:06.453034 x.x.x.x:5060 -> z.z.z.z:5060 INVITE sip:44123456789@z.z.z.z:5060 SIP/2.0. Record-Route: sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. Content-Type: application/sdp. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 229. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 16. . v=0. o=Quintum 7 7 IN IP4 a.b.c.d. s=VoipCall. c=IN IP4 a.b.c.d. t=0 0. m=audio 10254 RTP/AVP 18 4 101. c=IN IP4 a.b.c.d. a=rtpmap:18 g729/8000/1. a=rtpmap:4 g723/8000/1. a=rtpmap:101 telephone-event/8000/1.

# U 2005/09/06 15:23:06.465531 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 100 trying -- your call is important to us. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Server: Sip EXpress router (0.8.99-dev (i386/linux)). Content-Length: 0. .

######## U 2005/09/06 15:23:12.785564 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

---

This is where the confusion starts, what path should the 183 take, or how is the path decided, is it the RURI, or from the RR, or does it not matter for 183

# U 2005/09/06 15:23:12.788274 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

---

and the OK below, should it not have gone to zzzz and then xxxx, as in RR, and should not the matching RR be stripped off

---

############### U 2005/09/06 15:23:16.610600 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.613003 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 a.b.c.d:5060 -> x.x.x.x:5060 ACK sip:x.x.x.x;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Route: sip:0044123456789@y.y.y.y:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 70. .

# U 2005/09/06 15:23:16.727888 x.x.x.x:5060 -> y.y.y.y:5060 ACK sip:0044123456789@y.y.y.y:5060 SIP/2.0. Record-Route: sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: sip:046677@a.b.c.d. From: sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Via: SIP/2.0/UDP x.x.x.x;branch=0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. Max-Forwards: 16. .

Jan Janak wrote:

...

Somehow the value from the first record-route got lost in the user agent. It put the bottom most Route in the request-uri (which is correct becuase the implemenetation is most likely a strict router), it also correctly turned the Contact from 200 OK into Route header field in the ACK, but the Route header field of the proxy (first one in 200 OK) is missing in the ACK.

Jan.

On 08-09-2005 13:12, Iqbal wrote:

...

Hi Bogdan

Getting a little clearer :-)

The Contact that ius used is that from the 200 OK which is sent before the ACK (as below), if so that explains where the .134 is coming from.

Also you mentioned that the last hop is taken, but I read somewhere that the topmost route is taken, when forming the route. If it is a strict router, does the RURI pick up the info from the Contact header OR the RR, Also should RURI not read 111.222.333.444 because that what is in the RR in the 200 OK which is sent, which is what the ACK is showing. Whereas in ur example it reads as below

b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: sip:0044123456789@212.156.5.134:5060

Now if the RURI is as it is in the ACK, the rest should be

Route: sip:0044123456789@212.156.5.135:5060.

I guess at the end of the day whatever it should be, it isn't, anyone know of howto fix it.

Iqbal

Bogdan-Andrei Iancu wrote:

...

Hi Iqbal,

the Route Set is formed by the all received RR uris and the Contact uri. When doing LR, the last hop from the Route Set in loaded into RURI and all RRs are loaded as Route. The request is not routed by RURI, but by the first Route hdr.

So, if the GW does LR and it generates RURI: sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on ,the request will be sent to the first Route (212.156.5.135), which will sent to 111.222.333.444, which will finally use RURI (212.156.5.134) as no other Route is left in request.

regards, bogdan

Iqbal wrote:

...

Hi

This makes a little sense :-), according to a), is the path now taken .444 --> .135, if so what does the RURI show.

If the path is that shown by Route headers, then I cannot send it to .134, since that gateway does not respond directly, and will reject the ACK.

Where does the RR, Route headers pick up the info from, I thought that the Route gets it from what is in the RR

Iqbal

On 9/7/2005, "Bogdan-Andrei Iancu" bogdan@voice-system.ro wrote:

>Hi Iqbal, > >considering 200 OK the Route Set: >RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on >RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on >CT: sip:0044123456789@212.156.5.134:5060 > >the ACK should be: >a)if loose router: >RURI: sip:0044123456789@212.156.5.134:5060 >R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on >R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on >b) if strict router: >RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on >R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on >R: sip:0044123456789@212.156.5.134:5060 > >the ACK you posted looks like an unsuccessful attempt of a strict >routing. > >regards, >bogdan > >Iqbal wrote: > > > > > > > >>Hi >> >>I have a strange looking dialogue, after sending a 200 OK to a quintum >>box, and get back an ACK, but the Route field seems to be wrong, can >>someone confirm this. >> >>-------- >>U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 >>SIP/2.0 200 OK. >>Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. >>From: sip:046677@10.20.30.40;tag=c3ac7b24-a. >>To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. >>Date: Tue, 06 Sep 2005 14:07:59 gmt. >>Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. >>Server: Cisco-SIPGateway/IOS-12.x. >>CSeq: 1 INVITE. >>Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, >>SUBSCRIBE, NOTIFY, INFO. >>Allow-Events: telephone-event. >>Contact: sip:0044123456789@212.156.5.134:5060. >>Record-Route: >>sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24-a;lr=on. >> >> >>Content-Type: application/sdp. >>Content-Length: 206. >>. >>v=0. >>o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. >>s=SIP Call. >>c=IN IP4 212.156.5.134. >>t=0 0. >>m=audio 18590 RTP/AVP 18. >>c=IN IP4 212.156.5.134. >>a=rtpmap:18 G729/8000. >>a=fmtp:18 annexb=yes. >> >># >>U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 >>ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. >>CSeq: 1 ACK. >>Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. >>Contact: sip:046677@10.20.30.40. >>From: sip:046677@10.20.30.40;tag=c3ac7b24-a. >>Route: sip:0044123456789@212.156.5.134:5060. >>Session-GUID: 859321956-876164920-926430820-875782963. >>To: sip:123456789@111.222.333.444;tag=1A4297F4-2C9. >>Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. >>User-Agent: Quintum/1.0.0. >>Quintum: >>0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. >> >> >>Max-Forwards: 70. >>---------------- >> >>I thought the Route field should have the data which it pulls from the >>Record Route headers >> >>tks >> >>iqbal >> >>_______________________________________________ >>Users mailing list >>Users@openser.org >>http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> > > > >

.

---

Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

.

---

Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

.

Iqbal writes:

RR tells the UA where future request should go, and Route tells the UA where the request that contains the Route should go...dont follow

iqbal,

you will find answers to these kind of questions in rfc3261. it would be fair if you would first try to find answers to your questions from the spec and if not successful, ask help from the list. for your particular question above, please read section 12 of rfc3261. it is better to use jan's resources on writing code than on repeating what rfc3261 says.

-- juha

Ouch!!

And I thought I had problems with Quintum!!! I've spent what seems like a life time trying to get Quintum Tenors to work with ser and nated ua's. For the life of me I can't figure out why a ua behind a Linksys nat router works with fix_nated_sdp but it doesn't with force_rtp_proxy. The setup is ua ==> nat ==> ser ==> quintum ==> PSTN. And a ua behind a Dlink nat router works with force_rtp_proxy but doesn't work with fix_nated_sdp. But if I use asterisk as a pstn gw, everything works fine with either sdp or rtp_proxy. Maybe if I could detect when each occurred I could implement the working configuration. Does anyone have any experience with this type of configuration? (systemic verses cone nat) I sure could use the help before I lose all my hair. Thanx

_____

From: serusers-bounces@iptel.org [mailto:serusers-bounces@iptel.org] On Behalf Of Kanakatti M. Subramanya Sent: Thursday, September 08, 2005 10:53 PM Cc: serusers@iptel.org; users openser.org Subject: Re: [Serusers] Re: [Users] Route, Record Route and quintum

Brilliantly, and quite eloquently detailed Jan. Thanx!

FYI, I spent a *looong* time flailing around with Quintium hardware trying to get it to do the *correct* thing (and it was for a three person account too!)

Finally gave up in disgust, depression and despair.

Mind you, this was just before I discovered that one of our major providers was switching to Sonus. Sonus, I ask you.

Yikes....

Jan Janak wrote:

OK, I think I know where the confusion comes from, it is like this:

When a user agent sends a SIP request, the request will traverse one ore more SIP proxies until it reaches the target user agent. Each proxy and user agent along the path of the request will add its Via header field. The purpose of Via header fields is to make sure that all replies will traverse exactly the same set of proxies (but in reverse order) as the request. In other words Via header fields are used to route _replies_. They record the path of the request so that replies can follow it.

Route and Record-Route header fields have a slightly different purpose -- they are used to route _requests_. Let's assume this scenario:

INV INV UA A --------> proxy ----------> UA B a@1.2.3.4 b@5.6.7.8

User agent A with IP address 1.2.3.4 sends an INVITE request to the proxy which forwards the request to user agent B. UA A adds the Contact header field in the request. The Contact header field tells UA B that it can reach UA A on IP 1.2.3.4. UA B adds a Contact header field to 200 OK reply, telling UA A that it can reach B on IP address 5.6.7.8. This way both user agents exchange their IP addresses and they do not need the proxy anymore. They can easily send all further SIP messages directly to each other, because they remember the IP address of the remote party from Contact header field. This way all further requests would bypass the proxy server.

There are many cases where the proxy server needs to see _all_ future SIP messages exchanged between the user agent (for example when performing accounting). In this case the proxy server needs tell the user agents that they should not exchange future SIP messages directly, but they should relay them through the proxy again.

The proxy server can do this by inserting Record-Route header field in the INVITE message. The Record-Route header field contains the IP address of the proxy and once the INVITE message reaches UA B, it extracts the IP address of the proxy server from Record-Route header field and store it in memory along with the IP address of the remote party (UA A). So UA B knows the IP address of UA A and it also knows that it should send all future requests to UA A through the proxy server.

UA A should also send all future SIP requests to UA B through the proxy server, but it does not know it yet, because the proxy server added Record-Route header field to the INVITE message (which will only reach UA B). UA B has to tell UA A that all future SIP requests should be sent through the proxy, and it does so by copying all Record-Route header fields (in our example there will be only one) from the INVITE message to 200 OK (which is sent from UA B to UA A). UA A will then extract Record-Route header fields along with Contact from 200 OK and store it in memory. At this point both user agents know the IP address of the remote party and that they should relay all SIP messages through the proxy.

Now what happens when UA A wants to send an ACK to UA B. It will lookup the IP address of the remote party (Contact from 200 OK) from memory and put

it in the Request-URI of ACK. The reason why ACK does not have the same Request-URI as the original INVITE is that the ACK should be sent to the user agent instance that generated 200 OK -- the Request-URI from the INVITE would fork if user B had several user agents and this is not desirable for ACKs. The URI based on Contact header field never forks, it is delivered only to the UA instance that generated 200 OK. UA A will also find the URI from the Record-Route header field in memory (stored along with the contact of the remote party). It will create a Route header field, put the URI in it and append it to the ACK.

RFC3261 says that if there is a Route header field in a SIP message, then the message should not be sent to the URI in the Request-URI, but to the URI in Route header field and thus the ACK would be sent to the proxy. The proxy will then remove the Route header field and because there is no other Route header field in our message, it will forward the request to the Request-URI which will take the message to UA B.

Note the difference between Record-Route and Route header fields. Record-Route header fields tell SIP user agent and proxies where _future_ SIP requests should be sent. Route header field are constructed from Record-Route header fields and they tell user agent and proxies where the request that contains the Route header fields should be sent. Two header field names are needed to avoid confusion, because a proxy server can add Record-Route header field to _any_ SIP request, including requests that already contain Route header fields (using the same name would mix them).

The relationship between the two user agents (when they remember the IP address of the remote party and IPs of proxies) is called dialog. SIP requests that are forwarded using the information extracted from Contacts and Record-Route header fields are called "SIP requests within dialog" (typically ACK and BYE).

When a user agent sends a SIP request within a dialog, it will always put the Contact of the remote party in the Request-URI and copy all URIs extracted from Record-Route header fields in Route header fields (in either forward or reverse order, based on the direction):

ACK sip:b@5.6.7.8 SIP/2.0 Route: sip:proxy@proxy.ip;lr ...

This is how all recent SIP implementations should behave. Always put the Contact of the remote party into the Request-URI and list all proxies that inserted Record-Route in Route header fields appended to the message. Plain and simple.

Unfortunately there are also older SIP implementations (from pre-RFC3261 era) that need special care, because record-routing worked differently then. In this case the Record-Route does not contain the contact of the remote party but the topmost Route header field, and the value of the remote contact is preserved in the last Route header field in the message. This "compatibility mode" is what makes record routing complex and hard to understand, but you can ignore it (you can always find details in RFC3261).

In conclusion:

1) Via is used to route responses 2) Route and Record-Route headers are used to route requests 3) Proxies use Record-Route to signal that they want to stay on the path of future requests. 4) User agents use Record-Route headers to build Route headers. 5) Contact of the remote party is always put in the Request-URI of requests in dialogs. 6) The list of Route header field is created from the list of Record-Route header fields. 7) The URI in the topmost Route header field overrides the URI in the Request-URI, so the Request-URI will only be used if there are no more Route header fields.

Jan.

PS: When talking to Quintum guys, you should ask them to implement what I just described: 1) Take the Contact header field from 200 OK and put it in the Request-URI of ACK. 2) Take all Record-Route header fields from 200 OK, reverse their order, and append them as Route header fields to the ACK. 3) Send the ACK to the topmost Route, if any, otherwise send to the Request-URI.

On 08-09-2005 19:23, Iqbal wrote:

Hi

Just in case I missed something, and before I trash quintum, I have put the entire dialogue below, to make sure I am getting it correct. If someone can take a quick look, cause loose routes and strict are driving me crazy The setup is quintum --- ser---gw (a.b.c.d ----x.x.x.x ----z.z.z.z)

quintum IP = a.b.c.d ser ip = x.x.x.x gw = z.z.z.z gw2 = y.y.y.y

Now you cannot get to gw2 direct

I have read the RFC, and it may as well be written in French. Also the Via headers which messages follow those.

From what i see we have

the RURI, The route headers and the via headers, which is followed and when

iqbal

U 2005/09/06 15:23:06.414932 a.b.c.d:5060 -> x.x.x.x:5060 INVITE sip:07866318220@x.x.x.x SIP/2.0. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d. Content-Type: application/sdp. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 229. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b 413031322d313033353941. Max-Forwards: 70. . v=0. o=Quintum 7 7 IN IP4 a.b.c.d. s=VoipCall. c=IN IP4 a.b.c.d. t=0 0. m=audio 10254 RTP/AVP 18 4 101. c=IN IP4 a.b.c.d. a=rtpmap:18 g729/8000/1. a=rtpmap:4 g723/8000/1. a=rtpmap:101 telephone-event/8000/1.

# U 2005/09/06 15:23:06.452476 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 100 trying -- your call is important to us. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 0. Warning: 392 x.x.x.x:5060 "Noisy feedback tells: pid=24439 req_src_ip=a.b.c.d req_src_port=5060 in_uri=sip:123456789@x.x.x.x out_uri=sip:447866318220@213.166.5.135:5060 via_cnt==1". .

# U 2005/09/06 15:23:06.453034 x.x.x.x:5060 -> z.z.z.z:5060 INVITE sip:44123456789@z.z.z.z:5060 SIP/2.0. Record-Route: sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d. Content-Type: application/sdp. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Content-Length: 229. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b 413031322d313033353941. Max-Forwards: 16. . v=0. o=Quintum 7 7 IN IP4 a.b.c.d. s=VoipCall. c=IN IP4 a.b.c.d. t=0 0. m=audio 10254 RTP/AVP 18 4 101. c=IN IP4 a.b.c.d. a=rtpmap:18 g729/8000/1. a=rtpmap:4 g723/8000/1. a=rtpmap:101 telephone-event/8000/1.

# U 2005/09/06 15:23:06.465531 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 100 trying -- your call is important to us. CSeq: 1 INVITE. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. Server: Sip EXpress router (0.8.99-dev (i386/linux)). Content-Length: 0. .

######## U 2005/09/06 15:23:12.785564 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow-Events: telephone-event. Contact: mailto:sip:0044123456789@y.y.y.y:5060 sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

------------------- This is where the confusion starts, what path should the 183 take, or how is the path decided, is it the RURI, or from the RR, or does it not matter for 183

# U 2005/09/06 15:23:12.788274 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow-Events: telephone-event. Contact: mailto:sip:0044123456789@y.y.y.y:5060 sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

---------------------- and the OK below, should it not have gone to zzzz and then xxxx, as in RR, and should not the matching RR be stripped off ----------------------

############### U 2005/09/06 15:23:16.610600 z.z.z.z:5060 -> x.x.x.x:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: mailto:sip:0044123456789@y.y.y.y:5060 sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.613003 x.x.x.x:5060 -> a.b.c.d:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: mailto:sip:0044123456789@y.y.y.y:5060 sip:0044123456789@y.y.y.y:5060. Record-Route: sip:z.z.z.z;ftag=c3ac7b24-a;lr=on,sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y. s=SIP Call. c=IN IP4 y.y.y.y. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 y.y.y.y. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 a.b.c.d:5060 -> x.x.x.x:5060 ACK sip:x.x.x.x;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. Route: mailto:sip:0044123456789@y.y.y.y:5060 sip:0044123456789@y.y.y.y:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b 413031322d313033353941. Max-Forwards: 70. .

# U 2005/09/06 15:23:16.727888 x.x.x.x:5060 -> y.y.y.y:5060 ACK sip:0044123456789@y.y.y.y:5060 SIP/2.0. Record-Route: sip:x.x.x.x;ftag=c3ac7b24-a;lr=on. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@a.b.c.d. Contact: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d. From: mailto:sip:046677@a.b.c.d sip:046677@a.b.c.d;tag=c3ac7b24-a. Session-GUID: 859321956-876164920-926430820-875782963. To: mailto:sip:123456789@x.x.x.x sip:123456789@x.x.x.x;tag=1A4297F4-2C9. Via: SIP/2.0/UDP x.x.x.x;branch=0. Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b 413031322d313033353941. Max-Forwards: 16. .

Jan Janak wrote:

Somehow the value from the first record-route got lost in the user agent. It put the bottom most Route in the request-uri (which is correct becuase the implemenetation is most likely a strict router), it also correctly turned the Contact from 200 OK into Route header field in the ACK, but the Route header field of the proxy (first one in 200 OK) is missing in the ACK.

Jan.

On 08-09-2005 13:12, Iqbal wrote:

Hi Bogdan

Getting a little clearer :-)

The Contact that ius used is that from the 200 OK which is sent before the ACK (as below), if so that explains where the .134 is coming from.

Also you mentioned that the last hop is taken, but I read somewhere that the topmost route is taken, when forming the route. If it is a strict router, does the RURI pick up the info from the Contact header OR the RR, Also should RURI not read 111.222.333.444 because that what is in the RR in the 200 OK which is sent, which is what the ACK is showing. Whereas in ur example it reads as below

b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060

Now if the RURI is as it is in the ACK, the rest should be

Route: mailto:sip:0044123456789@212.156.5.135:5060 sip:0044123456789@212.156.5.135:5060.

I guess at the end of the day whatever it should be, it isn't, anyone know of howto fix it.

Iqbal

Bogdan-Andrei Iancu wrote:

Hi Iqbal,

the Route Set is formed by the all received RR uris and the Contact uri. When doing LR, the last hop from the Route Set in loaded into RURI and all RRs are loaded as Route. The request is not routed by RURI, but by the first Route hdr.

So, if the GW does LR and it generates RURI: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on ,the request will be sent to the first Route (212.156.5.135), which will sent to 111.222.333.444, which will finally use RURI (212.156.5.134) as no other Route is left in request.

regards, bogdan

Iqbal wrote:

Hi

This makes a little sense :-), according to a), is the path now taken .444 --> .135, if so what does the RURI show.

If the path is that shown by Route headers, then I cannot send it to .134, since that gateway does not respond directly, and will reject the ACK.

Where does the RR, Route headers pick up the info from, I thought that the Route gets it from what is in the RR

Iqbal

On 9/7/2005, "Bogdan-Andrei Iancu" mailto:bogdan@voice-system.ro bogdan@voice-system.ro wrote:

Hi Iqbal,

considering 200 OK the Route Set: RR: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on RR: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on CT: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060

the ACK should be: a)if loose router: RURI: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060 R: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on b) if strict router: RURI: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on R: sip:111.222.333.444;ftag=c3ac7b24-a;lr=on R: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060

the ACK you posted looks like an unsuccessful attempt of a strict routing.

regards, bogdan

Iqbal wrote:

Hi

I have a strange looking dialogue, after sending a 200 OK to a quintum box, and get back an ACK, but the Route field seems to be wrong, can someone confirm this.

-------- U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. From: mailto:sip:046677@10.20.30.40 sip:046677@10.20.30.40;tag=c3ac7b24-a. To: mailto:sip:123456789@111.222.333.444 sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Date: Tue, 06 Sep 2005 14:07:59 gmt. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 1 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. Allow-Events: telephone-event. Contact: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060. Record-Route: sip:212.156.5.135;ftag=c3ac7b24-a;lr=on,sip:111.222.333.444;ftag=c3ac7b24 -a;lr=on.

Content-Type: application/sdp. Content-Length: 206. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134. s=SIP Call. c=IN IP4 212.156.5.134. t=0 0. m=audio 18590 RTP/AVP 18. c=IN IP4 212.156.5.134. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes.

# U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060 ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0. CSeq: 1 ACK. Call-ID: call-00CC9E9D-4FBE-D311-0207-A@10.20.30.40. Contact: mailto:sip:046677@10.20.30.40 sip:046677@10.20.30.40. From: mailto:sip:046677@10.20.30.40 sip:046677@10.20.30.40;tag=c3ac7b24-a. Route: mailto:sip:0044123456789@212.156.5.134:5060 sip:0044123456789@212.156.5.134:5060. Session-GUID: 859321956-876164920-926430820-875782963. To: mailto:sip:123456789@111.222.333.444 sip:123456789@111.222.333.444;tag=1A4297F4-2C9. Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018. User-Agent: Quintum/1.0.0. Quintum: 0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b 413031322d313033353941.

Max-Forwards: 70. ----------------

I thought the Route field should have the data which it pulls from the Record Route headers

tks

iqbal

_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

.

_______________________________________________ Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

.

_______________________________________________ Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

_______________________________________________ Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers

Brilliantly, and quite eloquently detailed Jan. Thanx!

FYI, I spent a *looong* time flailing around with Quintium hardware trying to get it to do the *correct* thing (and it was for a three person account too!)

Finally gave up in disgust, depression and despair.

Mind you, this was just before I discovered that one of our major providers was switching to Sonus. Sonus, I ask you.

Yikes....

Jan Janak wrote:

OK, I think I know where the confusion comes from, it is like this:

When a user agent sends a SIP request, the request will traverse one ore more SIP proxies until it reaches the target user agent. Each proxy and user agent along the path of the request will add its Via header field. The purpose of Via header fields is to make sure that all replies will traverse exactly the same set of proxies (but in reverse order) as the request. In other words Via header fields are used to route _replies_. They record the path of the request so that replies can follow it.

Route and Record-Route header fields have a slightly different purpose -- they are used to route _requests_. Let's assume this scenario:

  INV               INV

UA A --------> proxy ----------> UA B a@1.2.3.4 b@5.6.7.8

User agent A with IP address 1.2.3.4 sends an INVITE request to the proxy which forwards the request to user agent B. UA A adds the Contact header field in the request. The Contact header field tells UA B that it can reach UA A on IP 1.2.3.4. UA B adds a Contact header field to 200 OK reply, telling UA A that it can reach B on IP address 5.6.7.8. This way both user agents exchange their IP addresses and they do not need the proxy anymore. They can easily send all further SIP messages directly to each other, because they remember the IP address of the remote party from Contact header field. This way all further requests would bypass the proxy server.

There are many cases where the proxy server needs to see _all_ future SIP messages exchanged between the user agent (for example when performing accounting). In this case the proxy server needs tell the user agents that they should not exchange future SIP messages directly, but they should relay them through the proxy again.

The proxy server can do this by inserting Record-Route header field in the INVITE message. The Record-Route header field contains the IP address of the proxy and once the INVITE message reaches UA B, it extracts the IP address of the proxy server from Record-Route header field and store it in memory along with the IP address of the remote party (UA A). So UA B knows the IP address of UA A and it also knows that it should send all future requests to UA A through the proxy server.

UA A should also send all future SIP requests to UA B through the proxy server, but it does not know it yet, because the proxy server added Record-Route header field to the INVITE message (which will only reach UA B). UA B has to tell UA A that all future SIP requests should be sent through the proxy, and it does so by copying all Record-Route header fields (in our example there will be only one) from the INVITE message to 200 OK (which is sent from UA B to UA A). UA A will then extract Record-Route header fields along with Contact from 200 OK and store it in memory. At this point both user agents know the IP address of the remote party and that they should relay all SIP messages through the proxy.

Now what happens when UA A wants to send an ACK to UA B. It will lookup the IP address of the remote party (Contact from 200 OK) from memory and put it in the Request-URI of ACK. The reason why ACK does not have the same Request-URI as the original INVITE is that the ACK should be sent to the user agent instance that generated 200 OK -- the Request-URI from the INVITE would fork if user B had several user agents and this is not desirable for ACKs. The URI based on Contact header field never forks, it is delivered only to the UA instance that generated 200 OK. UA A will also find the URI from the Record-Route header field in memory (stored along with the contact of the remote party). It will create a Route header field, put the URI in it and append it to the ACK.

RFC3261 says that if there is a Route header field in a SIP message, then the message should not be sent to the URI in the Request-URI, but to the URI in Route header field and thus the ACK would be sent to the proxy. The proxy will then remove the Route header field and because there is no other Route header field in our message, it will forward the request to the Request-URI which will take the message to UA B.

Note the difference between Record-Route and Route header fields. Record-Route header fields tell SIP user agent and proxies where _future_ SIP requests should be sent. Route header field are constructed from Record-Route header fields and they tell user agent and proxies where the request that contains the Route header fields should be sent. Two header field names are needed to avoid confusion, because a proxy server can add Record-Route header field to _any_ SIP request, including requests that already contain Route header fields (using the same name would mix them).

The relationship between the two user agents (when they remember the IP address of the remote party and IPs of proxies) is called dialog. SIP requests that are forwarded using the information extracted from Contacts and Record-Route header fields are called "SIP requests within dialog" (typically ACK and BYE).

When a user agent sends a SIP request within a dialog, it will always put the Contact of the remote party in the Request-URI and copy all URIs extracted from Record-Route header fields in Route header fields (in either forward or reverse order, based on the direction):

ACK sip:b@5.6.7.8 SIP/2.0 Route: sip:proxy@proxy.ip;lr ...

This is how all recent SIP implementations should behave. Always put the Contact of the remote party into the Request-URI and list all proxies that inserted Record-Route in Route header fields appended to the message. Plain and simple.

Unfortunately there are also older SIP implementations (from pre-RFC3261 era) that need special care, because record-routing worked differently then. In this case the Record-Route does not contain the contact of the remote party but the topmost Route header field, and the value of the remote contact is preserved in the last Route header field in the message. This "compatibility mode" is what makes record routing complex and hard to understand, but you can ignore it (you can always find details in RFC3261).

In conclusion:

1. Via is used to route responses
2. Route and Record-Route headers are used to route requests
3. Proxies use Record-Route to signal that they want to stay on the path

of future requests. 4) User agents use Record-Route headers to build Route headers. 5) Contact of the remote party is always put in the Request-URI of requests in dialogs. 6) The list of Route header field is created from the list of Record-Route header fields. 7) The URI in the topmost Route header field overrides the URI in the Request-URI, so the Request-URI will only be used if there are no more Route header fields.

 Jan.

PS: When talking to Quintum guys, you should ask them to implement what I just described:

1. Take the Contact header field from 200 OK and put it in the Request-URI of ACK.
2. Take all Record-Route header fields from 200 OK, reverse their order, and append them as Route header fields to the ACK.
3. Send the ACK to the topmost Route, if any, otherwise send to the Request-URI.