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:[EMAIL PROTECTED] SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:[EMAIL PROTECTED]:5060;user=phone>;tag=366454712.
To:
"911211389"<sip:[EMAIL PROTECTED]:5060>;tag=c0a80a5b-13c4-193-66
314-2037.
Contact: <sip:[EMAIL PROTECTED]>.
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]:5060;user=phone>;tag=366454712.
To:
"911211389"<sip:[EMAIL PROTECTED]:5060>;tag=c0a80a5b-13c4-193-66
314-2037.
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] out_uri=sip:[EMAIL PROTECTED]
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:[EMAIL PROTECTED] SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:[EMAIL PROTECTED]:5060;user=phone>;tag=3946763066.
To:
"911211389"<sip:[EMAIL PROTECTED]:5060>;tag=c0a80a5b-13c4-d7-3839c-1
12.
Contact: <sip:[EMAIL PROTECTED]>.
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]:5060;user=phone>;tag=3946763066.
To:
"911211389"<sip:[EMAIL PROTECTED]:5060>;tag=c0a80a5b-13c4-d7-3839c-1
12.
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]:1025 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.7:5060;branch=z9hG4bK4871D0D.
From: <sip:[EMAIL PROTECTED]:5060;user=phone>;tag=A4968CC-159E.
To:
"911211389"<sip:[EMAIL PROTECTED]:5060>;tag=c0a80a5b-13c4-e170-3
70da02-2ec0.
Date: Thu, 22 Dec 2005 09:20:14 GMT.
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]
Enviado el: martes, 20 de diciembre de 2005 17:12
Para: Pepe
CC: [email protected]
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:
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:
>/ 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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
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.
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
