[Users] LCR problem
Klaus Darilion
klaus.mailinglists at pernau.at
Thu Dec 22 13:57:45 CET 2005
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-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 Users
mailing list