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:[EMAIL PROTECTED]
Enviado el: jueves, 22 de diciembre de 2005 13:58
Para: Pepe
CC: [email protected]
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:[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-3
> 839c-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-3
> 839c-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.
>
>
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
