20 Dec
2005
20 Dec
'05
1:22 p.m.
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
20 Dec
20 Dec
5:11 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
21 Dec
21 Dec
5:47 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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:
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,
/>/
/>/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:22 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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:
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,
/>/
/>/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
22 Dec
22 Dec
11:45 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)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:
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,
/>/
/>/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1:57 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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:
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,
/>/
/>/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
10 Jan
10 Jan
9:57 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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:
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,
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:
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,
/>/
/>/ 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6680
days inactive
6701
days old
6 comments
2 participants
participants (2)
-
Klaus Darilion -
Pepe