[Users] LCR problem

Pepe jlbravo at acotelsa.com
Tue Jan 10 09:57:24 CET 2006


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 at pernau.at] 
Enviado el: jueves, 22 de diciembre de 2005 13:58
Para: Pepe
CC: users at 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 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-3
> 839c-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-3
> 839c-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.
> 
> 



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 Users mailing list