[Serusers] Re: [Users] Route, Record Route and quintum
Iqbal
iqbal at gigo.co.uk
Thu Sep 8 14:48:17 CEST 2005
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 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