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 extrangebehavior, 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
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 myGW2, 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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hello,
Here you have the ngrep:
[root@LinuxDPP ~]# ngrep -W byline -t port 5060 interface: eth0 (192.168.10.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 2005/12/21 17:45:56.147290 83.175.204.142:1025 -> 192.168.10.93:5060 INVITE sip:669086199@192.168.10.93:5060;user=phone SIP/2.0. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Max-Forwards: 70. Supported: replaces. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Content-Type: application/SDP. Content-Length: 262. . v=0. o=SIP302 12367 0 IN IP4 192.168.10.91. s=SIP302 Session. c=IN IP4 83.175.204.142. t=0 0. m=audio 16384 RTP/AVP 18 4 0 0. a=ptime:20. a=ptime:30. a=ptime:20. a=ptime:0. a=rtpmap:18 G729/8000. a=rtpmap:4 G723/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:0 PCMU/8000.
# U 2005/12/21 17:45:56.168527 192.168.10.93:5060 -> 83.175.204.142:1025 SIP/2.0 100 trying -- your call is important to us. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Content-Length: 0. Warning: 392 192.168.10.93:5060 "Noisy feedback tells: pid=3909 req_src_ip=83.175.204.142 req_src_port=1025 in_uri=sip:669086199@192.168.10.93:5060;user=phone out_uri=sip:669086199@195.219.74.166:5060;user=phone via_cnt==1". .
# U 2005/12/21 17:45:56.169244 192.168.10.93:5060 -> 195.219.74.166:5060 INVITE sip:669086199@195.219.74.166:5060;user=phone SIP/2.0. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Max-Forwards: 69. Supported: replaces. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Content-Type: application/SDP. Content-Length: 262. . v=0. o=SIP302 12367 0 IN IP4 192.168.10.91. s=SIP302 Session. c=IN IP4 83.175.204.142. t=0 0. m=audio 16384 RTP/AVP 18 4 0 0. a=ptime:20. a=ptime:30. a=ptime:20. a=ptime:0. a=rtpmap:18 G729/8000. a=rtpmap:4 G723/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:0 PCMU/8000.
# U 2005/12/21 17:45:56.507603 195.219.74.166:5060 -> 192.168.10.93:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Length: 0. .
# U 2005/12/21 17:46:01.709394 195.219.74.166:5060 -> 192.168.10.93:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:01.715602 192.168.10.93:5060 -> 83.175.204.142:1025 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:03.718973 195.219.74.166:5060 -> 192.168.10.93:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Contact: sip:34669086199@195.219.74.166. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:03.726139 192.168.10.93:5060 -> 83.175.204.142:1025 SIP/2.0 200 OK. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Contact: sip:34669086199@195.219.74.166. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:03.880319 83.175.204.142:1025 -> 192.168.10.93:5060 ACK sip:34669086199@195.219.74.166 SIP/2.0. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 ACK. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1f7-7e888-25f8. Max-Forwards: 70. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Route: sip:192.168.10.93;lr;ftag=c0a80a5b-13c4-1ef-7ca38-206a. Content-Length: 0. .
# U 2005/12/21 17:46:03.896380 192.168.10.93:5060 -> 195.219.74.166:5060 ACK sip:34669086199@195.219.74.166 SIP/2.0. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 ACK. Via: SIP/2.0/UDP 192.168.10.93;branch=0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1f7-7e888-25f8. Max-Forwards: 69. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Content-Length: 0. P-hint: rr-enforced. .
# U 2005/12/21 17:46:06.677243 195.219.74.166:5060 -> 192.168.10.93:5060 BYE sip:911211389@192.168.10.93 SIP/2.0. Via: SIP/2.0/UDP 195.219.74.166:5060;branch=1. From: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. To: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. Contact: sip:34669086199@195.219.74.166. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 2 BYE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Length: 0. .
# U 2005/12/21 17:46:07.082683 192.168.10.93:5060 -> 195.219.74.166:5060 SIP/2.0 483 Too Many Hops. Via: SIP/2.0/UDP 195.219.74.166:5060;branch=1. From: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. To: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 2 BYE. Content-Length: 0. Warning: 392 192.168.10.93:5060 "Noisy feedback tells: pid=3909 req_src_ip=192.168.10.93 req_src_port=5060 in_uri=sip:911211389@192.168.10.93 out_uri=sip:911211389@192.168.10.93 via_cnt==12". .
exit 15 received, 0 dropped
Thx for all...
-----Mensaje original----- De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Enviado el: martes, 20 de diciembre de 2005 17:12 Para: Pepe CC: users@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 myGW2, 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@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.
Very simple - the callee (a gateway?) is broken. It does not include the proper Route header.
regards klaus
Pepe wrote:
Hello,
Here you have the ngrep:
[root@LinuxDPP ~]# ngrep -W byline -t port 5060 interface: eth0 (192.168.10.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 2005/12/21 17:45:56.147290 83.175.204.142:1025 -> 192.168.10.93:5060 INVITE sip:669086199@192.168.10.93:5060;user=phone SIP/2.0. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Max-Forwards: 70. Supported: replaces. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Content-Type: application/SDP. Content-Length: 262. . v=0. o=SIP302 12367 0 IN IP4 192.168.10.91. s=SIP302 Session. c=IN IP4 83.175.204.142. t=0 0. m=audio 16384 RTP/AVP 18 4 0 0. a=ptime:20. a=ptime:30. a=ptime:20. a=ptime:0. a=rtpmap:18 G729/8000. a=rtpmap:4 G723/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:0 PCMU/8000.
# U 2005/12/21 17:45:56.168527 192.168.10.93:5060 -> 83.175.204.142:1025 SIP/2.0 100 trying -- your call is important to us. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Content-Length: 0. Warning: 392 192.168.10.93:5060 "Noisy feedback tells: pid=3909 req_src_ip=83.175.204.142 req_src_port=1025 in_uri=sip:669086199@192.168.10.93:5060;user=phone out_uri=sip:669086199@195.219.74.166:5060;user=phone via_cnt==1". .
# U 2005/12/21 17:45:56.169244 192.168.10.93:5060 -> 195.219.74.166:5060 INVITE sip:669086199@195.219.74.166:5060;user=phone SIP/2.0. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Max-Forwards: 69. Supported: replaces. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Content-Type: application/SDP. Content-Length: 262. . v=0. o=SIP302 12367 0 IN IP4 192.168.10.91. s=SIP302 Session. c=IN IP4 83.175.204.142. t=0 0. m=audio 16384 RTP/AVP 18 4 0 0. a=ptime:20. a=ptime:30. a=ptime:20. a=ptime:0. a=rtpmap:18 G729/8000. a=rtpmap:4 G723/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:0 PCMU/8000.
# U 2005/12/21 17:45:56.507603 195.219.74.166:5060 -> 192.168.10.93:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Length: 0. .
# U 2005/12/21 17:46:01.709394 195.219.74.166:5060 -> 192.168.10.93:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:01.715602 192.168.10.93:5060 -> 83.175.204.142:1025 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:03.718973 195.219.74.166:5060 -> 192.168.10.93:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.10.93;branch=z9hG4bKd6af.aaf5bbe7.0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Contact: sip:34669086199@195.219.74.166. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:03.726139 192.168.10.93:5060 -> 83.175.204.142:1025 SIP/2.0 200 OK. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1ef-7ca42-495b. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 INVITE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Contact: sip:34669086199@195.219.74.166. Content-Type: application/sdp. Content-Length: 187. . v=0. o=- 134 1 IN IP4 195.219.74.166. s=-. c=IN IP4 195.219.74.166. t=0 0. m=audio 29000 RTP/AVP 4 96. a=rtpmap:4 G723/8000. a=ptime:60. a=rtpmap:96 telephone-event/8000. a=fmtp:96 0-15.
# U 2005/12/21 17:46:03.880319 83.175.204.142:1025 -> 192.168.10.93:5060 ACK sip:34669086199@195.219.74.166 SIP/2.0. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 ACK. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1f7-7e888-25f8. Max-Forwards: 70. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Route: sip:192.168.10.93;lr;ftag=c0a80a5b-13c4-1ef-7ca38-206a. Content-Length: 0. .
# U 2005/12/21 17:46:03.896380 192.168.10.93:5060 -> 195.219.74.166:5060 ACK sip:34669086199@195.219.74.166 SIP/2.0. Record-Route: sip:192.168.10.93;ftag=c0a80a5b-13c4-1ef-7ca38-206a;lr=on. From: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. To: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 1 ACK. Via: SIP/2.0/UDP 192.168.10.93;branch=0. Via: SIP/2.0/UDP 83.175.204.142:1025;branch=z9hG4bK-1f7-7e888-25f8. Max-Forwards: 69. User-Agent: SIP Phone. Contact: sip:911211389@83.175.204.142:1025. Content-Length: 0. P-hint: rr-enforced. .
# U 2005/12/21 17:46:06.677243 195.219.74.166:5060 -> 192.168.10.93:5060 BYE sip:911211389@192.168.10.93 SIP/2.0. Via: SIP/2.0/UDP 195.219.74.166:5060;branch=1. From: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. To: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. Contact: sip:34669086199@195.219.74.166. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 2 BYE. Allow: INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER. Content-Length: 0. .
# U 2005/12/21 17:46:07.082683 192.168.10.93:5060 -> 195.219.74.166:5060 SIP/2.0 483 Too Many Hops. Via: SIP/2.0/UDP 195.219.74.166:5060;branch=1. From: sip:669086199@192.168.10.93:5060;user=phone;tag=937175270. To: "911211389"sip:911211389@192.168.10.93:5060;tag=c0a80a5b-13c4-1ef-7ca38-20 6a. Call-ID: 8057fe48-c0a80a5b-13c4-1ef-7ca38-450c@83.175.204.140. CSeq: 2 BYE. Content-Length: 0. Warning: 392 192.168.10.93:5060 "Noisy feedback tells: pid=3909 req_src_ip=192.168.10.93 req_src_port=5060 in_uri=sip:911211389@192.168.10.93 out_uri=sip:911211389@192.168.10.93 via_cnt==12". .
exit 15 received, 0 dropped
Thx for all...
-----Mensaje original----- De: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Enviado el: martes, 20 de diciembre de 2005 17:12 Para: Pepe CC: users@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@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.
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@192.168.10.93 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1. From: sip:669086199@openser.pruebas.com:5060;user=phone;tag=366454712. To: "911211389"sip:911211389@openser.pruebas.com:5060;tag=c0a80a5b-13c4-193-66 314-2037. Contact: sip:34669086199@195.0.0.6. Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1@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@openser.pruebas.com:5060;user=phone;tag=366454712. To: "911211389"sip:911211389@openser.pruebas.com:5060;tag=c0a80a5b-13c4-193-66 314-2037. Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1@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@192.168.10.93 out_uri=sip:911211389@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@192.168.24.85 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1. From: sip:669086199@ser.pruebas.com:5060;user=phone;tag=3946763066. To: "911211389"sip:911211389@ser.pruebas.com:5060;tag=c0a80a5b-13c4-d7-3839c-1 12. Contact: sip:34669086199@195.0.0.6. Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74@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@ser.pruebas.com:5060;user=phone;tag=3946763066. To: "911211389"sip:911211389@ser.pruebas.com:5060;tag=c0a80a5b-13c4-d7-3839c-1 12. Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74@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@83.175.204.142:1025 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.7:5060;branch=z9hG4bK4871D0D. From: sip:669086199@openser.pruebas.com:5060;user=phone;tag=A4968CC-159E. To: "911211389"sip:911211389@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@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@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@pernau.at] Enviado el: martes, 20 de diciembre de 2005 17:12 Para: Pepe CC: users@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 myGW2, 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@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.
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@192.168.10.93 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1. From: sip:669086199@openser.pruebas.com:5060;user=phone;tag=366454712. To: "911211389"sip:911211389@openser.pruebas.com:5060;tag=c0a80a5b-13c4-193-66 314-2037. Contact: sip:34669086199@195.0.0.6. Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1@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@openser.pruebas.com:5060;user=phone;tag=366454712. To: "911211389"sip:911211389@openser.pruebas.com:5060;tag=c0a80a5b-13c4-193-66 314-2037. Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1@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@192.168.10.93 out_uri=sip:911211389@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@192.168.24.85 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1. From: sip:669086199@ser.pruebas.com:5060;user=phone;tag=3946763066. To: "911211389"sip:911211389@ser.pruebas.com:5060;tag=c0a80a5b-13c4-d7-3839c-1 12. Contact: sip:34669086199@195.0.0.6. Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74@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@ser.pruebas.com:5060;user=phone;tag=3946763066. To: "911211389"sip:911211389@ser.pruebas.com:5060;tag=c0a80a5b-13c4-d7-3839c-1 12. Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74@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@83.175.204.142:1025 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.7:5060;branch=z9hG4bK4871D0D. From: sip:669086199@openser.pruebas.com:5060;user=phone;tag=A4968CC-159E. To: "911211389"sip:911211389@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@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@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@pernau.at] Enviado el: martes, 20 de diciembre de 2005 17:12 Para: Pepe CC: users@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@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.
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@pernau.at] Enviado el: jueves, 22 de diciembre de 2005 13:58 Para: Pepe CC: users@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@192.168.10.93 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1. From: sip:669086199@openser.pruebas.com:5060;user=phone;tag=366454712. To: "911211389"sip:911211389@openser.pruebas.com:5060;tag=c0a80a5b-13c4- 193-66 314-2037. Contact: sip:34669086199@195.0.0.6. Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1@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@openser.pruebas.com:5060;user=phone;tag=366454712. To: "911211389"sip:911211389@openser.pruebas.com:5060;tag=c0a80a5b-13c4- 193-66 314-2037. Call-ID: 8057ff64-c0a80a5b-13c4-193-66314-6ad1@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@192.168.10.93 out_uri=sip:911211389@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@192.168.24.85 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.6:5060;branch=1. From: sip:669086199@ser.pruebas.com:5060;user=phone;tag=3946763066. To: "911211389"sip:911211389@ser.pruebas.com:5060;tag=c0a80a5b-13c4-d7-3 839c-1 12. Contact: sip:34669086199@195.0.0.6. Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74@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@ser.pruebas.com:5060;user=phone;tag=3946763066. To: "911211389"sip:911211389@ser.pruebas.com:5060;tag=c0a80a5b-13c4-d7-3 839c-1 12. Call-ID: 8057fccc-c0a80a5b-13c4-d7-3839c-7b74@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@83.175.204.142:1025 SIP/2.0. Via: SIP/2.0/UDP 195.0.0.7:5060;branch=z9hG4bK4871D0D. From:
sip:669086199@openser.pruebas.com:5060;user=phone;tag=A4968CC-159E.
To: "911211389"sip:911211389@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@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@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@pernau.at] Enviado el: martes, 20 de diciembre de 2005 17:12 Para: Pepe CC: users@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@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.
-
Klaus Darilion -
Pepe