[Serusers] Re: [Users] Route, Record Route and quintum

Iqbal iqbal at gigo.co.uk
Thu Sep 8 20:23:39 CEST 2005


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 at x.x.x.x SIP/2.0.
CSeq: 1 INVITE.
Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
Contact: <sip:046677 at a.b.c.d>.
Content-Type: application/sdp.
From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
Session-GUID: 859321956-876164920-926430820-875782963.
To: <sip:123456789 at 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 at a.b.c.d.
From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
To: <sip:123456789 at 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 at x.x.x.x 
out_uri=sip:447866318220 at 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 at 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 at a.b.c.d.
Contact: <sip:046677 at a.b.c.d>.
Content-Type: application/sdp.
From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
Session-GUID: 859321956-876164920-926430820-875782963.
To: <sip:123456789 at 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 at a.b.c.d.
From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
To: <sip:123456789 at 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 at a.b.c.d>;tag=c3ac7b24-a.
To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
Date: Tue, 06 Sep 2005 14:07:59 gmt.
Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 1 INVITE.
Allow-Events: telephone-event.
Contact: <sip:0044123456789 at 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 at a.b.c.d>;tag=c3ac7b24-a.
To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
Date: Tue, 06 Sep 2005 14:07:59 gmt.
Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
Server: Cisco-SIPGateway/IOS-12.x.
CSeq: 1 INVITE.
Allow-Events: telephone-event.
Contact: <sip:0044123456789 at 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 at a.b.c.d>;tag=c3ac7b24-a.
To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
Date: Tue, 06 Sep 2005 14:07:59 gmt.
Call-ID: call-00CC9E9D-4FBE-D311-0207-A at 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 at 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 at a.b.c.d>;tag=c3ac7b24-a.
To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
Date: Tue, 06 Sep 2005 14:07:59 gmt.
Call-ID: call-00CC9E9D-4FBE-D311-0207-A at 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 at 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 at a.b.c.d.
Contact: <sip:046677 at a.b.c.d>.
From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
Route: <sip:0044123456789 at y.y.y.y:5060>.
Session-GUID: 859321956-876164920-926430820-875782963.
To: <sip:123456789 at 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 at 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 at a.b.c.d.
Contact: <sip:046677 at a.b.c.d>.
From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
Session-GUID: 859321956-876164920-926430820-875782963.
To: <sip:123456789 at 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 at 212.156.5.134:5060>
>>
>>Now if the RURI is as it is in the ACK, the rest should be
>>
>>Route: <sip:0044123456789 at 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 at 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 at 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 at 212.156.5.134:5060>
>>>>>
>>>>>the ACK should be:
>>>>>a)if loose router:
>>>>> RURI: <sip:0044123456789 at 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 at 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 at 10.20.30.40>;tag=c3ac7b24-a.
>>>>>>To: <sip:123456789 at 111.222.333.444>;tag=1A4297F4-2C9.
>>>>>>Date: Tue, 06 Sep 2005 14:07:59 gmt.
>>>>>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at 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 at 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 at 10.20.30.40.
>>>>>>Contact: <sip:046677 at 10.20.30.40>.
>>>>>>From: <sip:046677 at 10.20.30.40>;tag=c3ac7b24-a.
>>>>>>Route: <sip:0044123456789 at 212.156.5.134:5060>.
>>>>>>Session-GUID: 859321956-876164920-926430820-875782963.
>>>>>>To: <sip:123456789 at 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 at openser.org
>>>>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>   
>>>>>>            
>>>>>>
>>>>> 
>>>>>
>>>>>          
>>>>>
>>>>
>>>>        
>>>>
>>>.
>>>
>>>      
>>>
>>_______________________________________________
>>Serusers mailing list
>>Serusers at iptel.org
>>http://mail.iptel.org/mailman/listinfo/serusers
>>    
>>
>
>.
>
>  
>




More information about the sr-users mailing list