8 Sep
2005
8 Sep
'05
2:48 p.m.
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:
_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers
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(a)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(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(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(a)openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>
>
>
>
.