[Users] LCR problem

Pepe jlbravo at acotelsa.com
Thu Dec 22 11:45:02 CET 2005


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 at 192.168.10.93 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:669086199 at openser.pruebas.com:5060;user=phone>;tag=366454712.
To:
"911211389"<sip:911211389 at openser.pruebas.com:5060>;tag=c0a80a5b-13c4-193-66
314-2037.
Contact: <sip:34669086199 at 195.0.0.6>.
Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1 at 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 at openser.pruebas.com:5060;user=phone>;tag=366454712.
To:
"911211389"<sip:911211389 at openser.pruebas.com:5060>;tag=c0a80a5b-13c4-193-66
314-2037.
Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1 at 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 at 192.168.10.93 out_uri=sip:911211389 at 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 at 192.168.24.85 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1.
From: <sip:669086199 at ser.pruebas.com:5060;user=phone>;tag=3946763066.
To:
"911211389"<sip:911211389 at ser.pruebas.com:5060>;tag=c0a80a5b-13c4-d7-3839c-1
12.
Contact: <sip:34669086199 at 195.0.0.6>.
Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74 at 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 at ser.pruebas.com:5060;user=phone>;tag=3946763066.
To:
"911211389"<sip:911211389 at ser.pruebas.com:5060>;tag=c0a80a5b-13c4-d7-3839c-1
12.
Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74 at 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 at 83.175.204.142:1025 SIP/2.0.
Via: SIP/2.0/UDP 195.0.0.7:5060;branch=z9hG4bK4871D0D.
From: <sip:669086199 at openser.pruebas.com:5060;user=phone>;tag=A4968CC-159E.
To:
"911211389"<sip:911211389 at 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 at 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 at 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 at pernau.at] 
Enviado el: martes, 20 de diciembre de 2005 17:12
Para: Pepe
CC: users at 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:
> 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
> Users at openser.org
> 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.





More information about the sr-users mailing list