10 Jan
2006
10 Jan
'06
10:57 a.m.
Hello,
Teles has fixed the SIP protocol and now it includes the headers.
Thx Klaus for help ppl.
Regards
-----Mensaje original-----
De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Enviado el: jueves, 22 de diciembre de 2005 13:58
Para: Pepe
CC: users(a)openser.org
Asunto: Re: [Users] LCR problem
Cisco is correct by using the Route: header and putting the clients Contact
into the request URI. This is called a "loose router" as defined in RFC
3261. The Cause Code header is optional.
Teles is incorrect as the mandatory Route header is missing. I wonder how it
works with ser. Maybe you have different configuration in ser and openser.
Thus, ser is able to route the request.
regards
klaus
Pepe wrote:
Hello again,
I have made some tests with the TELES GW is failing and a cisco GW
and my SER and OPENSER proxies. I have found some differences between
de BYE from TELES GW and Cisco GW, but I found something extrange the
BYE from the TELES works fine with the SER proxy and is the same
format it uses with OPENSER, btw I have send the traces to TELES to
study the problem, this are the BYE traces from the tests:
BYE TELES OPENSER
U 2005/12/22 11:01:15.841486 195.0.0.6:5060 -> 192.168.10.93:5060 BYE
sip:911211389@192.168.10.93 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:669086199@openser.pruebas.com:5060;user=phone>;tag=366454712.
To:
"911211389"<sip:911211389@openser.pruebas.com:5060>;tag=c0a80a5b-13c4-
193-66
314-2037.
Contact: <sip:34669086199@195.0.0.6>.
Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1(a)openser.pruebas.com.
CSeq: 2 BYE.
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER.
Content-Length: 0.
.
#
U 2005/12/22 11:01:16.294422 192.168.10.93:5060 -> 195.0.0.6:5060
SIP/2.0 483 Too Many Hops.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:669086199@openser.pruebas.com:5060;user=phone>;tag=366454712.
To:
"911211389"<sip:911211389@openser.pruebas.com:5060>;tag=c0a80a5b-13c4-
193-66
314-2037.
Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1(a)openser.pruebas.com.
CSeq: 2 BYE.
Content-Length: 0.
Warning: 392 192.168.10.93:5060 "Noisy feedback tells: pid=5116
req_src_ip=192.168.10.93 req_src_port=5060
in_uri=sip:911211389@192.168.10.93 out_uri=sip:911211389@192.168.10.93
via_cnt==12".
BYE TELES SER
#
U 2005/12/22 10:50:32.275885 195.0.0.6:5060 -> 192.168.24.85:5060 BYE
sip:911211389@192.168.24.85 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:669086199@ser.pruebas.com:5060;user=phone>;tag=3946763066.
To:
"911211389"<sip:911211389@ser.pruebas.com:5060>;tag=c0a80a5b-13c4-d7-3
839c-1
12.
Contact: <sip:34669086199@195.0.0.6>.
Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74(a)ser.pruebas.com.
CSeq: 3 BYE.
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER.
Content-Length: 0.
.
#
U 2005/12/22 10:50:32.609477 192.168.24.85:5060 -> 195.0.0.6:5060
SIP/2.0 200 OK.
From: <sip:669086199@ser.pruebas.com:5060;user=phone>;tag=3946763066.
To:
"911211389"<sip:911211389@ser.pruebas.com:5060>;tag=c0a80a5b-13c4-d7-3
839c-1
12.
Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74(a)ser.pruebas.com.
CSeq: 3 BYE.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
Supported: replaces.
User-Agent: SIP Phone.
Content-Length: 0.
.
BYE CISCO OPENSER
U 2005/12/22 10:21:49.461868 195.0.0.7:52696 -> 192.168.10.93:5060 BYE
sip:911211389@83.175.204.142:1025 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.7:5060;branch=z9hG4bK4871D0D.
From:
<sip:669086199@openser.pruebas.com:5060;user=phone>;tag=A4968CC-159E.
To:
"911211389"<sip:911211389@openser.pruebas.com:5060>;tag=c0a80a5b-13c4-
e170-3
70da02-2ec0.
Date: Thu, 22 Dec 2005 09:20:14 GMT.
Call-ID: 8057fccc-c0a80a5b-13c4-e170-370da02-79f2(a)openser.pruebas.com.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Max-Forwards: 5.
Route: <sip:192.168.10.93;ftag=c0a80a5b-13c4-e170-370da02-2ec0;lr=on>.
Timestamp: 1135243217.
CSeq: 101 BYE.
Reason: Q.850;cause=16.
Content-Length: 0.
The differences are:
Cisco use the client address in the header, a Route and a Release cause:
BYE sip:911211389@83.175.204.142:1025 SIP/2.0
Route:
<sip:192.168.10.93;ftag=c0a80a5b-13c4-e170-370da02-2ec0;lr=on>.
Reason: Q.850;cause=16.
Are this the differences that are causing the failure ????
Regards and thx to all.
-----Mensaje original-----
De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Enviado el: martes, 20 de diciembre de 2005 17:12
Para: Pepe
CC: users(a)openser.org
Asunto: Re: [Users] LCR problem
Hi Pepe!
This is not an ngrep, but a full ethereal decode. This is unreadable.
Please use "ngrep -W byline -t port 5060"
regards
klaus
Pepe wrote:
Mensaje analizado por el Sistema de Detección de Virus McAfee de Acotel. El
hecho de que dicho mensaje haya sido tratado NO excluye que pueda contener
virus no catalogados a fecha de hoy.
----------------------------------------
Message analyzed by the McAfee Virus Detection System at Acotel. The fact
that this message has passed analysis doesn't exclude the possibility of
being infected by an undetected virus.
Hello,
Im making tests and its not a LCR problem, its a problem from my
GW2, when I use it for first option, it fails too, here you have the
ngrep,
ClientA --> Proxy
--> GW2
(192.168.10.93) (192.168.10.91)
(195.219.74.166)
Regards
The problem is that the BYE request will be handled by your LCR logic.
The BYE request should be route in the loose_route block as it is an
in-dialog request. Maybe the BYE sent from the gateway is not correct.
Please post a ngrep dump (ngrep -t -W byline port 5060)
regards
klaus
Pepe wrote:
Mensaje analizado por el Sistema de Detección de Virus McAfee de
Acotel. El hecho de que dicho mensaje haya sido tratado NO excluye que
pueda contener virus no catalogados a fecha de hoy.
----------------------------------------
Message analyzed by the McAfee Virus Detection System at Acotel. The
fact that this message has passed analysis doesn't exclude the
possibility of being infected by an undetected virus.
/ Hello,
/>/
/>/ Im configuring Openser with LCR module and Im having an extrange
/>/ behavior, I have 2 gateways, GW1(preference1) and
GW2(preference2), />/
/>/ GW1(pref.1)
/>/ / \
/>/ ClientA --> OpenSer -->
Client B
/>/ \ GW2 (pref.2)
/
/>/
/>/
/>/ When I call from Client A to Client B using GW1, all works fine,
its the />/ same when hang up Client B or Client A, but when GW1
fail(I provoke it />/ changing codec) and use failure route (GW 2)
then if Client A hang up />/ all works fine, but the problem is when
is Client B who hang up, its />/ like a new conversation, GW 2 send
BYE to openser and Openser just send />/ "503 Service Not avilable -
No gateways" to GW2, but doesnt send nothing />/ to ClientA, any idea
????
/>/
/>/
/>/ Thx in advance
/>/
/
----------------------------------------------------------------------
--
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users