20 Feb
2007
20 Feb
'07
7:57 a.m.
Hello,
I have a question on how to configure the dialog module ( 1.2.x from
cvs yesterday ).
With my config, ( attached) I can make calls and have verified that
the acc module is working correctly.
My question is, when I enable the dialog module, I can see that it is
incrementing call count correctly, but when a bye is received, the
dialog:active_dialogs statistic is never decremented.
In the debug level 9 logs, ( also attached) I see this error after the
200OK is sent to the bye:
1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1 (delete=0)-> 1
Is this a case of one of the timers being set too short? by the way
using a variable call length from well under a second ( using sipp )
to 20 second call doesnt' seem to make a difference .
Thanks,
Andy
21 Feb
21 Feb
10:44 p.m.
Hi Andy,
could you check on the net if the BYE contain the Route hdr added to
INVITE as Record-Route? I have some doubts on this as I see:
0(966) find_first_route: No Route headers found
0(966) loose_route: There is no Route HF
and if the BYE is not identified, the dialog is not closed.
regards,
bogdan
Andy Pyles wrote:
Hello,
I have a question on how to configure the dialog module ( 1.2.x from
cvs yesterday ).
With my config, ( attached) I can make calls and have verified that
the acc module is working correctly.
My question is, when I enable the dialog module, I can see that it is
incrementing call count correctly, but when a bye is received, the
dialog:active_dialogs statistic is never decremented.
In the debug level 9 logs, ( also attached) I see this error after the
200OK is sent to the bye:
1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1 (delete=0)-> 1
Is this a case of one of the timers being set too short? by the way
using a variable call length from well under a second ( using sipp )
to 20 second call doesnt' seem to make a difference .
Thanks,
Andy
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
22 Feb
22 Feb
6:14 a.m.
HI Bogdan,
thanks for your reply.
yes you are correct. The Bye doesn't have the Route header.
It appears the the 200 OK sent to the caller doesn't contain a
Record-route header.
Messages between openser and callee contain record-route information,
but messages between caller and openser do not.
Is there a way to enable that?
Here's more detail:
192.168.0.101 = Caller (sipp)
1.2.3.4 = openser
4.3.2.1 = callee ( sipp)
1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
sip:service@1.2.3.4:5060, with session description
2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
sip:service@4.3.2.1:5060, with session description
4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session
description
6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session
description
8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK sip:service@1.2.3.4:5060
9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060
10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE sip:service@1.2.3.4:5060
11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060
12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
---
Packets 6,7 and following contain no Record-route information.
The other weird thing is that openser is passing on the Route: header
it recevied from callee to the caller.
Please see attached for complete ngrep output.
On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
could you check on the net if the BYE contain the Route hdr added to
INVITE as Record-Route? I have some doubts on this as I see:
0(966) find_first_route: No Route headers found
0(966) loose_route: There is no Route HF
and if the BYE is not identified, the dialog is not closed.
regards,
bogdan
Andy Pyles wrote:
Hello,
I have a question on how to configure the dialog module ( 1.2.x from
cvs yesterday ).
With my config, ( attached) I can make calls and have verified that
the acc module is working correctly.
My question is, when I enable the dialog module, I can see that it is
incrementing call count correctly, but when a bye is received, the
dialog:active_dialogs statistic is never decremented.
In the debug level 9 logs, ( also attached) I see this error after the
200OK is sent to the bye:
1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1 (delete=0)-> 1
Is this a case of one of the timers being set too short? by the way
using a variable call length from well under a second ( using sipp )
to 20 second call doesnt' seem to make a difference .
Thanks,
Andy
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:59 a.m.
Hi Andy,
so it's about sipp :D - I remember I had some hard times to make it work
with record Route.
take a look at the attached files, they might help you.
regards,
bogdan
Andy Pyles wrote:
HI Bogdan,
thanks for your reply.
yes you are correct. The Bye doesn't have the Route header.
It appears the the 200 OK sent to the caller doesn't contain a
Record-route header.
Messages between openser and callee contain record-route information,
but messages between caller and openser do not.
Is there a way to enable that?
Here's more detail:
192.168.0.101 = Caller (sipp)
1.2.3.4 = openser
4.3.2.1 = callee ( sipp)
1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
sip:service@1.2.3.4:5060, with session description
2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
sip:service@4.3.2.1:5060, with session description
4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session
description
6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session
description
8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
sip:service@1.2.3.4:5060
9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060
10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
sip:service@1.2.3.4:5060
11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060
12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
---
Packets 6,7 and following contain no Record-route information.
The other weird thing is that openser is passing on the Route: header
it recevied from callee to the caller.
Please see attached for complete ngrep output.
On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
could you check on the net if the BYE contain the Route hdr added to
INVITE as Record-Route? I have some doubts on this as I see:
0(966) find_first_route: No Route headers found
0(966) loose_route: There is no Route HF
and if the BYE is not identified, the dialog is not closed.
regards,
bogdan
Andy Pyles wrote:
------------------------------------------------------------------------
interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 5060 )
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
INVITE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Server: OpenSer (1.2.0-pre6-notls (i386/linux)).
Content-Length: 0.
Warning: 392 1.2.3.4:5060 "Noisy feedback tells: pid=22746 req_src_ip=192.168.0.101
req_src_port=5060 in_uri=sip:service@1.2.3.4:5060 out_uri=sip:service@4.3.2.1:5060
via_cnt==1".
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
INVITE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
ACK sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
ACK sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.2.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
BYE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
BYE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
exit
39 received, 0 dropped
Hello,
I have a question on how to configure the dialog module ( 1.2.x from
cvs yesterday ).
With my config, ( attached) I can make calls and have verified that
the acc module is working correctly.
My question is, when I enable the dialog module, I can see that it is
incrementing call count correctly, but when a bye is received, the
dialog:active_dialogs statistic is never decremented.
In the debug level 9 logs, ( also attached) I see this error after the
200OK is sent to the bye:
1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1
(delete=0)-> 1
Is this a case of one of the timers being set too short? by the way
using a variable call length from well under a second ( using sipp )
to 20 second call doesnt' seem to make a difference .
Thanks,
Andy
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
7:34 p.m.
HI Bogdan,
I'm already using an almsot identical version of uas.xml and uac.xml (
yes rrs=true) is being used. However in your version the uas.xml
doesn't have rrs="true" after initial invite which I think is needed.
See as you can see below, setting rrs="true" for uac will only work if
it receives a Record-Route header in the 200OK which it's not.
In this case, ALL messages from openser to sipp uac do not contain the
Record-route header. So I don't think it's a sipp problem, but an
openser configuration problem. I've tried using other devices for a
uac, such as x-lite but the same problem.
Andy
On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
so it's about sipp :D - I remember I had some hard times to make it work
with record Route.
take a look at the attached files, they might help you.
regards,
bogdan
Andy Pyles wrote:
HI Bogdan,
thanks for your reply.
yes you are correct. The Bye doesn't have the Route header.
It appears the the 200 OK sent to the caller doesn't contain a
Record-route header.
Messages between openser and callee contain record-route information,
but messages between caller and openser do not.
Is there a way to enable that?
Here's more detail:
192.168.0.101 = Caller (sipp)
1.2.3.4 = openser
4.3.2.1 = callee ( sipp)
1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
sip:service@1.2.3.4:5060, with session description
2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
sip:service@4.3.2.1:5060, with session description
4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session
description
6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session
description
8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
sip:service@1.2.3.4:5060
9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060
10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
sip:service@1.2.3.4:5060
11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060
12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
---
Packets 6,7 and following contain no Record-route information.
The other weird thing is that openser is passing on the Route: header
it recevied from callee to the caller.
Please see attached for complete ngrep output.
On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
could you check on the net if the BYE contain the Route hdr added to
INVITE as Record-Route? I have some doubts on this as I see:
0(966) find_first_route: No Route headers found
0(966) loose_route: There is no Route HF
and if the BYE is not identified, the dialog is not closed.
regards,
bogdan
Andy Pyles wrote:
------------------------------------------------------------------------
interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 5060 )
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
INVITE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Server: OpenSer (1.2.0-pre6-notls (i386/linux)).
Content-Length: 0.
Warning: 392 1.2.3.4:5060 "Noisy feedback tells: pid=22746 req_src_ip=192.168.0.101
req_src_port=5060 in_uri=sip:service@1.2.3.4:5060 out_uri=sip:service@4.3.2.1:5060
via_cnt==1".
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
INVITE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
ACK sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
ACK sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.2.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
BYE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
BYE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
exit
39 received, 0 dropped
Hello,
I have a question on how to configure the dialog module ( 1.2.x from
cvs yesterday ).
With my config, ( attached) I can make calls and have verified that
the acc module is working correctly.
My question is, when I enable the dialog module, I can see that it is
incrementing call count correctly, but when a bye is received, the
dialog:active_dialogs statistic is never decremented.
In the debug level 9 logs, ( also attached) I see this error after the
200OK is sent to the bye:
1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1
(delete=0)-> 1
Is this a case of one of the timers being set too short? by the way
using a variable call length from well under a second ( using sipp )
to 20 second call doesnt' seem to make a difference .
Thanks,
Andy
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
23 Feb
23 Feb
9:56 a.m.
Hi Bogdan,
After running additional debugs, for some reason the call to
loose_route() is failing.
if (loose_route()) {
# mark routing logic in request
xlog("L_INFO", "loose_route() succeeded\n ");
route(1);
} else{
xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu
T=$tu IP=$si ID=$ci\n");
};
Any ideas why this could be occuring?
On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
HI Bogdan,
I'm already using an almsot identical version of uas.xml and uac.xml (
yes rrs=true) is being used. However in your version the uas.xml
doesn't have rrs="true" after initial invite which I think is needed.
See as you can see below, setting rrs="true" for uac will only work if
it receives a Record-Route header in the 200OK which it's not.
In this case, ALL messages from openser to sipp uac do not contain the
Record-route header. So I don't think it's a sipp problem, but an
openser configuration problem. I've tried using other devices for a
uac, such as x-lite but the same problem.
Andy
On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
so it's about sipp :D - I remember I had some hard times to make it work
with record Route.
take a look at the attached files, they might help you.
regards,
bogdan
Andy Pyles wrote:
HI Bogdan,
thanks for your reply.
yes you are correct. The Bye doesn't have the Route header.
It appears the the 200 OK sent to the caller doesn't contain a
Record-route header.
Messages between openser and callee contain record-route information,
but messages between caller and openser do not.
Is there a way to enable that?
Here's more detail:
192.168.0.101 = Caller (sipp)
1.2.3.4 = openser
4.3.2.1 = callee ( sipp)
1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
sip:service@1.2.3.4:5060, with session description
2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
sip:service@4.3.2.1:5060, with session description
4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session
description
6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session
description
8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
sip:service@1.2.3.4:5060
9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060
10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
sip:service@1.2.3.4:5060
11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060
12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
---
Packets 6,7 and following contain no Record-route information.
The other weird thing is that openser is passing on the Route: header
it recevied from callee to the caller.
Please see attached for complete ngrep output.
On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
could you check on the net if the BYE contain the Route hdr added to
INVITE as Record-Route? I have some doubts on this as I see:
0(966) find_first_route: No Route headers found
0(966) loose_route: There is no Route HF
and if the BYE is not identified, the dialog is not closed.
regards,
bogdan
Andy Pyles wrote:
> Hello,
>
> I have a question on how to configure the dialog module ( 1.2.x from
> cvs yesterday ).
>
> With my config, ( attached) I can make calls and have verified that
> the acc module is working correctly.
>
> My question is, when I enable the dialog module, I can see that it is
> incrementing call count correctly, but when a bye is received, the
> dialog:active_dialogs statistic is never decremented.
>
> In the debug level 9 logs, ( also attached) I see this error after the
> 200OK is sent to the bye:
>
> 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1
(delete=0)-> 1
>
> Is this a case of one of the timers being set too short? by the way
> using a variable call length from well under a second ( using sipp )
> to 20 second call doesnt' seem to make a difference .
>
>
> Thanks,
> Andy
>
------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
------------------------------------------------------------------------
interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 5060 )
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
INVITE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Server: OpenSer (1.2.0-pre6-notls (i386/linux)).
Content-Length: 0.
Warning: 392 1.2.3.4:5060 "Noisy feedback tells: pid=22746 req_src_ip=192.168.0.101
req_src_port=5060 in_uri=sip:service@1.2.3.4:5060 out_uri=sip:service@4.3.2.1:5060
via_cnt==1".
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
INVITE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
ACK sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
ACK sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.2.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
BYE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
BYE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
exit
39 received, 0 dropped
11:38 a.m.
I Just re-read the docs on loose_route(). So please disregard this
question. ( only processed if Route: header is present. Which isn't
present because Record-route: header isn't being sent to caller )
So, I'm still trying to figure out why record-route: header is not
being sent to caller.
On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
Hi Bogdan,
After running additional debugs, for some reason the call to
loose_route() is failing.
if (loose_route()) {
# mark routing logic in request
xlog("L_INFO", "loose_route() succeeded\n ");
route(1);
} else{
xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu
T=$tu IP=$si ID=$ci\n");
};
Any ideas why this could be occuring?
On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
HI Bogdan,
I'm already using an almsot identical version of uas.xml and uac.xml (
yes rrs=true) is being used. However in your version the uas.xml
doesn't have rrs="true" after initial invite which I think is needed.
See as you can see below, setting rrs="true" for uac will only work if
it receives a Record-Route header in the 200OK which it's not.
In this case, ALL messages from openser to sipp uac do not contain the
Record-route header. So I don't think it's a sipp problem, but an
openser configuration problem. I've tried using other devices for a
uac, such as x-lite but the same problem.
Andy
On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi Andy,
so it's about sipp :D - I remember I had some hard times to make it work
with record Route.
take a look at the attached files, they might help you.
regards,
bogdan
Andy Pyles wrote:
HI Bogdan,
thanks for your reply.
yes you are correct. The Bye doesn't have the Route header.
It appears the the 200 OK sent to the caller doesn't contain a
Record-route header.
Messages between openser and callee contain record-route information,
but messages between caller and openser do not.
Is there a way to enable that?
Here's more detail:
192.168.0.101 = Caller (sipp)
1.2.3.4 = openser
4.3.2.1 = callee ( sipp)
1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
sip:service@1.2.3.4:5060, with session description
2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
sip:service@4.3.2.1:5060, with session description
4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session
description
6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session
description
8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
sip:service@1.2.3.4:5060
9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060
10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
sip:service@1.2.3.4:5060
11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060
12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
---
Packets 6,7 and following contain no Record-route information.
The other weird thing is that openser is passing on the Route: header
it recevied from callee to the caller.
Please see attached for complete ngrep output.
On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
> Hi Andy,
>
> could you check on the net if the BYE contain the Route hdr added to
> INVITE as Record-Route? I have some doubts on this as I see:
> 0(966) find_first_route: No Route headers found
> 0(966) loose_route: There is no Route HF
>
> and if the BYE is not identified, the dialog is not closed.
>
> regards,
> bogdan
>
> Andy Pyles wrote:
> > Hello,
> >
> > I have a question on how to configure the dialog module ( 1.2.x from
> > cvs yesterday ).
> >
> > With my config, ( attached) I can make calls and have verified that
> > the acc module is working correctly.
> >
> > My question is, when I enable the dialog module, I can see that it is
> > incrementing call count correctly, but when a bye is received, the
> > dialog:active_dialogs statistic is never decremented.
> >
> > In the debug level 9 logs, ( also attached) I see this error after the
> > 200OK is sent to the bye:
> >
> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1
> (delete=0)-> 1
> >
> > Is this a case of one of the timers being set too short? by the way
> > using a variable call length from well under a second ( using sipp )
> > to 20 second call doesnt' seem to make a difference .
> >
> >
> > Thanks,
> > Andy
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
> >
>
>
------------------------------------------------------------------------
interface: lo (127.0.0.0/255.0.0.0)
filter: (ip or ip6) and ( port 5060 )
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
INVITE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Server: OpenSer (1.2.0-pre6-notls (i386/linux)).
Content-Length: 0.
Warning: 392 1.2.3.4:5060 "Noisy feedback tells: pid=22746 req_src_ip=192.168.0.101
req_src_port=5060 in_uri=sip:service@1.2.3.4:5060 out_uri=sip:service@4.3.2.1:5060
via_cnt==1".
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
INVITE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.0.101.
s=-.
c=IN IP4 192.168.0.101.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-0.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 INVITE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Type: application/sdp.
Content-Length: 125.
.
v=0.
o=user1 53655765 2353687637 IN IP4 4.3.2.1.
s=-.
c=IN IP4 4.3.2.1.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
ACK sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
ACK sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKa6e8.b1ea5ac3.2.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-5.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 1 ACK.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 192.168.0.101:5060 -> 1.2.3.4:5060
BYE sip:service@1.2.3.4:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 4.3.2.1:5060
BYE sip:service@4.3.2.1:5060 SIP/2.0.
Record-Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001>.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Contact: sip:sipp@192.168.0.101:5060.
Max-Forwards: 69.
Subject: Performance Test.
Content-Length: 0.
.
#
U 4.3.2.1:5060 -> 1.2.3.4:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK76e8.ecad2904.0.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
#
U 1.2.3.4:5060 -> 192.168.0.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.101:5060;branch=z9hG4bK-1-7.
From: sipp <sip:sipp@192.168.0.101:5060>;tag=22779SIPpTag001.
To: sut <sip:service@1.2.3.4:5060>;tag=22700SIPpTag014.
Call-ID: 1-22779(a)192.168.0.101.
CSeq: 2 BYE.
Route: <sip:1.2.3.4;lr=on;ftag=22779SIPpTag001;did=052.8857fe74>.
Contact: <sip:4.3.2.1:5060;transport=UDP>.
Content-Length: 0.
.
exit
39 received, 0 dropped
3:54 p.m.
Hi Andy,
in client config, you need to add "[routes]" for ACK and BYE messages
(take a look at the cfg I sent you)
regards,
bogdan
Andy Pyles wrote:
I Just re-read the docs on loose_route(). So please
disregard this
question. ( only processed if Route: header is present. Which isn't
present because Record-route: header isn't being sent to caller )
So, I'm still trying to figure out why record-route: header is not
being sent to caller.
On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
> Hi Bogdan,
>
> After running additional debugs, for some reason the call to
> loose_route() is failing.
>
> if (loose_route()) {
> # mark routing logic in request
> xlog("L_INFO", "loose_route() succeeded\n ");
> route(1);
> } else{
> xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu
> T=$tu IP=$si ID=$ci\n");
> };
>
>
> Any ideas why this could be occuring?
>
>
> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
> > HI Bogdan,
> >
> > I'm already using an almsot identical version of uas.xml and uac.xml (
> > yes rrs=true) is being used. However in your version the uas.xml
> > doesn't have rrs="true" after initial invite which I think is
needed.
> > See as you can see below, setting rrs="true" for uac will only work
if
> > it receives a Record-Route header in the 200OK which it's not.
> >
> > In this case, ALL messages from openser to sipp uac do not contain the
> > Record-route header. So I don't think it's a sipp problem, but an
> > openser configuration problem. I've tried using other devices for a
> > uac, such as x-lite but the same problem.
> >
> > Andy
> >
> > On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
> > > Hi Andy,
> > >
> > > so it's about sipp :D - I remember I had some hard times to make
> it work
> > > with record Route.
> > >
> > > take a look at the attached files, they might help you.
> > >
> > > regards,
> > > bogdan
> > >
> > > Andy Pyles wrote:
> > > > HI Bogdan,
> > > >
> > > > thanks for your reply.
> > > > yes you are correct. The Bye doesn't have the Route header.
> > > > It appears the the 200 OK sent to the caller doesn't contain a
> > > > Record-route header.
> > > > Messages between openser and callee contain record-route
> information,
> > > > but messages between caller and openser do not.
> > > > Is there a way to enable that?
> > > >
> > > > Here's more detail:
> > > > 192.168.0.101 = Caller (sipp)
> > > > 1.2.3.4 = openser
> > > > 4.3.2.1 = callee ( sipp)
> > > >
> > > >
> > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
> > > > sip:service@1.2.3.4:5060, with session description
> > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
> > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
> > > > sip:service@4.3.2.1:5060, with session description
> > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
> > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with
> session
> > > > description
> > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
> > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with
> session
> > > > description
> > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
> > > > sip:service@1.2.3.4:5060
> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK
> sip:service@4.3.2.1:5060
> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
> > > > sip:service@1.2.3.4:5060
> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE
> sip:service@4.3.2.1:5060
> > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
> > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
> > > >
> > > > ---
> > > > Packets 6,7 and following contain no Record-route information.
> > > > The other weird thing is that openser is passing on the Route:
> header
> > > > it recevied from callee to the caller.
> > > >
> > > >
> > > > Please see attached for complete ngrep output.
> > > >
> > > >
> > > > On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
> > > >> Hi Andy,
> > > >>
> > > >> could you check on the net if the BYE contain the Route hdr
> added to
> > > >> INVITE as Record-Route? I have some doubts on this as I see:
> > > >> 0(966) find_first_route: No Route headers found
> > > >> 0(966) loose_route: There is no Route HF
> > > >>
> > > >> and if the BYE is not identified, the dialog is not closed.
> > > >>
> > > >> regards,
> > > >> bogdan
> > > >>
> > > >> Andy Pyles wrote:
> > > >> > Hello,
> > > >> >
> > > >> > I have a question on how to configure the dialog module (
> 1.2.x from
> > > >> > cvs yesterday ).
> > > >> >
> > > >> > With my config, ( attached) I can make calls and have
> verified that
> > > >> > the acc module is working correctly.
> > > >> >
> > > >> > My question is, when I enable the dialog module, I can see
> that it is
> > > >> > incrementing call count correctly, but when a bye is
> received, the
> > > >> > dialog:active_dialogs statistic is never decremented.
> > > >> >
> > > >> > In the debug level 9 logs, ( also attached) I see this error
> after the
> > > >> > 200OK is sent to the bye:
> > > >> >
> > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1
> > > >> (delete=0)-> 1
> > > >> >
> > > >> > Is this a case of one of the timers being set too short? by
> the way
> > > >> > using a variable call length from well under a second (
> using sipp )
> > > >> > to 20 second call doesnt' seem to make a difference .
> > > >> >
> > > >> >
> > > >> > Thanks,
> > > >> > Andy
> > > >> >
5:05 p.m.
Hi Michel,
looking at the net capture, it seams that the UAS device (User-Agent:
WLAN660-S VoIP PHONE) does not correctly mirror the RR header - it is
removing the hdr parameters, mirroring only the URI, which is bogus.
regards,
bogdan
Michel Bensoussan wrote:
Hello
I also have a similar problem. The dialog module doesn't detect the
BYE message.
I'm using ver 1.1.1.
My configuration is as follow: 2 Wifi SIP phones (BCM) connected to
the same Access Point and the OpenSER runs on a PC.
Attached the debug log, ethereal sniffing on the *Wire* LAN and my
config file.
For both ACK and BYE message, the dialog module prints the error
DEBUG:dialog:dlg_onroute: Route param 'did' not found
Did you find a solution?
If you want to check the attached files:
Caller: 192.168.13.166
Callee: 192.168.13.101
SIP Proxy: 192.168.13.86
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Andy,
>
> in client config, you need to add "[routes]" for ACK and BYE messages
> (take a look at the cfg I sent you)
>
> regards,
> bogdan
>
> Andy Pyles wrote:
>> I Just re-read the docs on loose_route(). So please disregard this
>> question. ( only processed if Route: header is present. Which isn't
>> present because Record-route: header isn't being sent to caller )
>>
>> So, I'm still trying to figure out why record-route: header is not
>> being sent to caller.
>>
>>
>> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
>>> Hi Bogdan,
>>>
>>> After running additional debugs, for some reason the call to
>>> loose_route() is failing.
>>>
>>> if (loose_route()) {
>>> # mark routing logic in request
>>> xlog("L_INFO", "loose_route() succeeded\n ");
>>> route(1);
>>> } else{
>>> xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru
F=$fu
>>> T=$tu IP=$si ID=$ci\n");
>>> };
>>>
>>>
>>> Any ideas why this could be occuring?
>>>
>>>
>>> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
>>> > HI Bogdan,
>>> >
>>> > I'm already using an almsot identical version of uas.xml and
>>> uac.xml (
>>> > yes rrs=true) is being used. However in your version the uas.xml
>>> > doesn't have rrs="true" after initial invite which I think
is
>>> needed.
>>> > See as you can see below, setting rrs="true" for uac will only
>>> work if
>>> > it receives a Record-Route header in the 200OK which it's not.
>>> >
>>> > In this case, ALL messages from openser to sipp uac do not
>>> contain the
>>> > Record-route header. So I don't think it's a sipp problem, but
an
>>> > openser configuration problem. I've tried using other devices for
a
>>> > uac, such as x-lite but the same problem.
>>> >
>>> > Andy
>>> >
>>> > On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
>>> > > Hi Andy,
>>> > >
>>> > > so it's about sipp :D - I remember I had some hard times to
>>> make it work
>>> > > with record Route.
>>> > >
>>> > > take a look at the attached files, they might help you.
>>> > >
>>> > > regards,
>>> > > bogdan
>>> > >
>>> > > Andy Pyles wrote:
>>> > > > HI Bogdan,
>>> > > >
>>> > > > thanks for your reply.
>>> > > > yes you are correct. The Bye doesn't have the Route
header.
>>> > > > It appears the the 200 OK sent to the caller doesn't
contain a
>>> > > > Record-route header.
>>> > > > Messages between openser and callee contain record-route
>>> information,
>>> > > > but messages between caller and openser do not.
>>> > > > Is there a way to enable that?
>>> > > >
>>> > > > Here's more detail:
>>> > > > 192.168.0.101 = Caller (sipp)
>>> > > > 1.2.3.4 = openser
>>> > > > 4.3.2.1 = callee ( sipp)
>>> > > >
>>> > > >
>>> > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
>>> > > > sip:service@1.2.3.4:5060, with session description
>>> > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
>>> > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
>>> > > > sip:service@4.3.2.1:5060, with session description
>>> > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
>>> > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK,
with
>>> session
>>> > > > description
>>> > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
>>> > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK,
with
>>> session
>>> > > > description
>>> > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
>>> > > > sip:service@1.2.3.4:5060
>>> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK
>>> sip:service@4.3.2.1:5060
>>> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
>>> > > > sip:service@1.2.3.4:5060
>>> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE
>>> sip:service@4.3.2.1:5060
>>> > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
>>> > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
>>> > > >
>>> > > > ---
>>> > > > Packets 6,7 and following contain no Record-route
information.
>>> > > > The other weird thing is that openser is passing on the
>>> Route: header
>>> > > > it recevied from callee to the caller.
>>> > > >
>>> > > >
>>> > > > Please see attached for complete ngrep output.
>>> > > >
>>> > > >
>>> > > > On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
wrote:
>>> > > >> Hi Andy,
>>> > > >>
>>> > > >> could you check on the net if the BYE contain the Route
hdr
>>> added to
>>> > > >> INVITE as Record-Route? I have some doubts on this as I
see:
>>> > > >> 0(966) find_first_route: No Route headers found
>>> > > >> 0(966) loose_route: There is no Route HF
>>> > > >>
>>> > > >> and if the BYE is not identified, the dialog is not
closed.
>>> > > >>
>>> > > >> regards,
>>> > > >> bogdan
>>> > > >>
>>> > > >> Andy Pyles wrote:
>>> > > >> > Hello,
>>> > > >> >
>>> > > >> > I have a question on how to configure the dialog
module (
>>> 1.2.x from
>>> > > >> > cvs yesterday ).
>>> > > >> >
>>> > > >> > With my config, ( attached) I can make calls and have
>>> verified that
>>> > > >> > the acc module is working correctly.
>>> > > >> >
>>> > > >> > My question is, when I enable the dialog module, I
can see
>>> that it is
>>> > > >> > incrementing call count correctly, but when a bye is
>>> received, the
>>> > > >> > dialog:active_dialogs statistic is never
decremented.
>>> > > >> >
>>> > > >> > In the debug level 9 logs, ( also attached) I see
this
>>> error after the
>>> > > >> > 200OK is sent to the bye:
>>> > > >> >
>>> > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98
with 1
>>> > > >> (delete=0)-> 1
>>> > > >> >
>>> > > >> > Is this a case of one of the timers being set too
short?
>>> by the way
>>> > > >> > using a variable call length from well under a
second (
>>> using sipp )
>>> > > >> > to 20 second call doesnt' seem to make a
difference .
>>> > > >> >
>>> > > >> >
>>> > > >> > Thanks,
>>> > > >> > Andy
>>> > > >> >
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
26 Feb
26 Feb
11:49 a.m.
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have to
handle the case it doesn't correctly mirror the RR header. Can we base
the dialog states on From and To headers? or Callid? I understand the
the rr_param is used for fast dialog matching (dialog README). Checking
dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michel,
looking at the net capture, it seams that the UAS device (User-Agent:
WLAN660-S VoIP PHONE) does not correctly mirror the RR header - it is
removing the hdr parameters, mirroring only the URI, which is bogus.
regards,
bogdan
Michel Bensoussan wrote:
Hello
I also have a similar problem. The dialog module doesn't detect the
BYE message.
I'm using ver 1.1.1.
My configuration is as follow: 2 Wifi SIP phones (BCM) connected to
the same Access Point and the OpenSER runs on a PC.
Attached the debug log, ethereal sniffing on the *Wire* LAN and my
config file.
For both ACK and BYE message, the dialog module prints the error
DEBUG:dialog:dlg_onroute: Route param 'did' not found
Did you find a solution?
If you want to check the attached files:
Caller: 192.168.13.166
Callee: 192.168.13.101
SIP Proxy: 192.168.13.86
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Andy,
>
> in client config, you need to add "[routes]" for ACK and BYE
> messages (take a look at the cfg I sent you)
>
> regards,
> bogdan
>
> Andy Pyles wrote:
>> I Just re-read the docs on loose_route(). So please disregard this
>> question. ( only processed if Route: header is present. Which isn't
>> present because Record-route: header isn't being sent to caller )
>>
>> So, I'm still trying to figure out why record-route: header is not
>> being sent to caller.
>>
>>
>> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
>>> Hi Bogdan,
>>>
>>> After running additional debugs, for some reason the call to
>>> loose_route() is failing.
>>>
>>> if (loose_route()) {
>>> # mark routing logic in request
>>> xlog("L_INFO", "loose_route() succeeded\n ");
>>> route(1);
>>> } else{
>>> xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru
F=$fu
>>> T=$tu IP=$si ID=$ci\n");
>>> };
>>>
>>>
>>> Any ideas why this could be occuring?
>>>
>>>
>>> On 2/22/07, Andy Pyles <andy.pyles(a)gmail.com> wrote:
>>> > HI Bogdan,
>>> >
>>> > I'm already using an almsot identical version of uas.xml and
>>> uac.xml (
>>> > yes rrs=true) is being used. However in your version the uas.xml
>>> > doesn't have rrs="true" after initial invite which I think
is
>>> needed.
>>> > See as you can see below, setting rrs="true" for uac will only
>>> work if
>>> > it receives a Record-Route header in the 200OK which it's not.
>>> >
>>> > In this case, ALL messages from openser to sipp uac do not
>>> contain the
>>> > Record-route header. So I don't think it's a sipp problem, but
an
>>> > openser configuration problem. I've tried using other devices
>>> for a
>>> > uac, such as x-lite but the same problem.
>>> >
>>> > Andy
>>> >
>>> > On 2/22/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
>>> > > Hi Andy,
>>> > >
>>> > > so it's about sipp :D - I remember I had some hard times to
>>> make it work
>>> > > with record Route.
>>> > >
>>> > > take a look at the attached files, they might help you.
>>> > >
>>> > > regards,
>>> > > bogdan
>>> > >
>>> > > Andy Pyles wrote:
>>> > > > HI Bogdan,
>>> > > >
>>> > > > thanks for your reply.
>>> > > > yes you are correct. The Bye doesn't have the Route
header.
>>> > > > It appears the the 200 OK sent to the caller doesn't
contain a
>>> > > > Record-route header.
>>> > > > Messages between openser and callee contain record-route
>>> information,
>>> > > > but messages between caller and openser do not.
>>> > > > Is there a way to enable that?
>>> > > >
>>> > > > Here's more detail:
>>> > > > 192.168.0.101 = Caller (sipp)
>>> > > > 1.2.3.4 = openser
>>> > > > 4.3.2.1 = callee ( sipp)
>>> > > >
>>> > > >
>>> > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE
>>> > > > sip:service@1.2.3.4:5060, with session description
>>> > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try
>>> > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE
>>> > > > sip:service@4.3.2.1:5060, with session description
>>> > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing
>>> > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK,
>>> with session
>>> > > > description
>>> > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing
>>> > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK,
>>> with session
>>> > > > description
>>> > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK
>>> > > > sip:service@1.2.3.4:5060
>>> > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK
>>> sip:service@4.3.2.1:5060
>>> > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE
>>> > > > sip:service@1.2.3.4:5060
>>> > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE
>>> sip:service@4.3.2.1:5060
>>> > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK
>>> > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
>>> > > >
>>> > > > ---
>>> > > > Packets 6,7 and following contain no Record-route
information.
>>> > > > The other weird thing is that openser is passing on the
>>> Route: header
>>> > > > it recevied from callee to the caller.
>>> > > >
>>> > > >
>>> > > > Please see attached for complete ngrep output.
>>> > > >
>>> > > >
>>> > > > On 2/21/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
wrote:
>>> > > >> Hi Andy,
>>> > > >>
>>> > > >> could you check on the net if the BYE contain the Route
hdr
>>> added to
>>> > > >> INVITE as Record-Route? I have some doubts on this as I
see:
>>> > > >> 0(966) find_first_route: No Route headers found
>>> > > >> 0(966) loose_route: There is no Route HF
>>> > > >>
>>> > > >> and if the BYE is not identified, the dialog is not
closed.
>>> > > >>
>>> > > >> regards,
>>> > > >> bogdan
>>> > > >>
>>> > > >> Andy Pyles wrote:
>>> > > >> > Hello,
>>> > > >> >
>>> > > >> > I have a question on how to configure the dialog
module
>>> ( 1.2.x from
>>> > > >> > cvs yesterday ).
>>> > > >> >
>>> > > >> > With my config, ( attached) I can make calls and have
>>> verified that
>>> > > >> > the acc module is working correctly.
>>> > > >> >
>>> > > >> > My question is, when I enable the dialog module, I
can
>>> see that it is
>>> > > >> > incrementing call count correctly, but when a bye is
>>> received, the
>>> > > >> > dialog:active_dialogs statistic is never
decremented.
>>> > > >> >
>>> > > >> > In the debug level 9 logs, ( also attached) I see
this
>>> error after the
>>> > > >> > 200OK is sent to the bye:
>>> > > >> >
>>> > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98
with 1
>>> > > >> (delete=0)-> 1
>>> > > >> >
>>> > > >> > Is this a case of one of the timers being set too
short?
>>> by the way
>>> > > >> > using a variable call length from well under a
second (
>>> using sipp )
>>> > > >> > to 20 second call doesnt' seem to make a
difference .
>>> > > >> >
>>> > > >> >
>>> > > >> > Thanks,
>>> > > >> > Andy
>>> > > >> >
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
9:05 p.m.
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support broken
stuff :)....doing dialog matching in traditional way (without using RR
stuff) is very costly and since complete, un-altered RR mirroring is
mandatory by RFC3261, I see no point of doing it different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have
to handle the case it doesn't correctly mirror the RR header. Can we
base the dialog states on From and To headers? or Callid? I understand
the the rr_param is used for fast dialog matching (dialog README).
Checking dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> looking at the net capture, it seams that the UAS device (User-Agent:
> WLAN660-S VoIP PHONE) does not correctly mirror the RR header - it is
> removing the hdr parameters, mirroring only the URI, which is bogus.
>
> regards,
> bogdan
27 Feb
27 Feb
8:53 a.m.
Hi
"I think the best approach is to force the UAC vendors to align to the
SIP specifications."
Well..... Good luck.
I don't know why but I think if I call and tell them "get back all you
products and upgrade them to align to the SIP specification" they won't
listen to me. But may be I'm wrong.
Any way. I have to deal with it. Do you have some suggestions? What is
the best dialog module version to start with?
I'm not familiar with SIP but I understand that the "To" header won't
change during a session. Is that right? I'm not sure the "CallID" will
be them same in case of re-INVITE.
So I can save the "To" header in the dialog table and check it if the
rm_param is not found.
I'm not sure how to do this.
Andy, If you have some suggestions too...
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support
broken stuff :)....doing dialog matching in traditional way (without
using RR stuff) is very costly and since complete, un-altered RR
mirroring is mandatory by RFC3261, I see no point of doing it
different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have
to handle the case it doesn't correctly mirror the RR header. Can we
base the dialog states on From and To headers? or Callid? I
understand the the rr_param is used for fast dialog matching (dialog
README). Checking dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> looking at the net capture, it seams that the UAS device
> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
> header - it is removing the hdr parameters, mirroring only the URI,
> which is bogus.
>
> regards,
> bogdan
9:32 a.m.
HI Michel,
Well here's what I'm doing:
if ( loose_route() {
if($DLG_status == 0 && method!="BYE" ){ *** assuming latest patch
accepted
xlog("L_INFO", "broken ua, dropping packet\n");
exit();
}
}
This isn't the most elegant solution, but in my case works ok.
Basically Lets say the UAC is broken. The first opportunity to tell it
is "broken" is when it sends an ACK to the 200 OK.
At this point, it would be very nice to have an option to send "BYE",
but as this functionality isn't there yet, we just reject the ACK, and
eventually the broken UAC will send a bye.
There may be other corner cases as well, but you get the general idea.
Andy
On 2/26/07, Michel Bensoussan <michel(a)extricom.com> wrote:
Hi
"I think the best approach is to force the UAC vendors to align to the
SIP specifications."
Well..... Good luck.
I don't know why but I think if I call and tell them "get back all you
products and upgrade them to align to the SIP specification" they won't
listen to me. But may be I'm wrong.
Any way. I have to deal with it. Do you have some suggestions? What is
the best dialog module version to start with?
I'm not familiar with SIP but I understand that the "To" header won't
change during a session. Is that right? I'm not sure the "CallID" will
be them same in case of re-INVITE.
So I can save the "To" header in the dialog table and check it if the
rm_param is not found.
I'm not sure how to do this.
Andy, If you have some suggestions too...
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support
broken stuff :)....doing dialog matching in traditional way (without
using RR stuff) is very costly and since complete, un-altered RR
mirroring is mandatory by RFC3261, I see no point of doing it
different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have
to handle the case it doesn't correctly mirror the RR header. Can we
base the dialog states on From and To headers? or Callid? I
understand the the rr_param is used for fast dialog matching (dialog
README). Checking dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> looking at the net capture, it seams that the UAS device
> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
> header - it is removing the hdr parameters, mirroring only the URI,
> which is bogus.
>
> regards,
> bogdan
10:56 a.m.
Hi
If I understand your solution, you don't allow the session. And what if
($dlg_count != 0) ?
I tried this. It seems to work but I just quick check it.
The key in "Callid" but I'm not sure it is a good choice. Maybe
"To" is
better.
Add the following function in dlg_hash.c:
(based on release 1.1.1)
struct dlg_cell* lookup_dlg_callid(str* callid)
{
struct dlg_cell *dlg;
struct dlg_entry *d_entry;
int i;
if (d_table==0)
goto not_found;
for( i=0 ; i<d_table->size; i++ ) {
d_entry = &(d_table->entries[i]);
dlg_lock( d_table, d_entry);
for( dlg=d_entry->first ; dlg ; dlg=dlg->next ) {
if (!memcmp(dlg->callid.s, callid->s, dlg->callid.len)) {
if (dlg->state==DLG_STATE_DELETED) {
dlg_unlock( d_table, d_entry);
goto not_found;
}
dlg->ref++;
dlg_unlock( d_table, d_entry);
DBG("DEBUG:dialog:lookup_dlg_callid: dialog callid='%.*s' found
on entry %u.%u\n",
callid->len, ZSW(callid->s), dlg->h_id, dlg->h_entry);
return dlg;
}
}
dlg_unlock( d_table, d_entry);
}
not_found:
DBG("DEBUG:dialog:lookup_dlg: no dialog callid='%.*s' found\n",
callid->len, ZSW(callid->s));
return 0;
}
In dlg_handlers.c, modify dlg_onroute() as following:
void dlg_onroute(struct sip_msg* req, str *route_params, void *param)
{
struct dlg_cell *dlg = 0;
str val;
str callid;
int h_entry;
int h_id;
/* If find rm_param do as previously */
if (d_rrb.get_route_param( req, &rr_param, &val) == 0) {
DBG("DEBUG:dialog:dlg_onroute: route param is '%.*s' (len=%d)\n",
val.len, val.s, val.len);
if ( parse_dlg_rr_param( val.s, val.s+val.len, &h_entry, &h_id)<0 )
return;
dlg = lookup_dlg( h_entry, h_id);
if (dlg==0) {
LOG(L_WARN,"WARNING:dialog:dlg_onroute: unable to find dialog\n");
return;
}
}else if (req->callid){
/* If rm_param not found, look for callid */
dlg = lookup_dlg_callid(&req->callid->body);
if (!dlg){
DBG("DEBUG:dialog:dlg_onroute: Callid '%.*s' not found\n",
req->callid->body.len, req->callid->body.s);
return;
}
}
if (use_tight_match) {
if ((!req->callid && parse_headers(req,HDR_CALLID_F,0)<0) ||
!req->callid) {
LOG(L_ERR, "ERROR:dialog:dlg_onroute: bad request or "
"missing CALLID hdr :-/\n");
return;
}
callid = req->callid->body;
trim(&callid);
if (dlg->callid.len!=callid.len ||
strncmp(dlg->callid.s,callid.s,callid.len)!=0) {
LOG(L_WARN,"WARNING:dialog:dlg_onroute: tight matching
failed\n");
return;
}
}
if (req->first_line.u.request.method_value==METHOD_BYE) {
if (remove_dlg_timer(&dlg->tl)!=0) {
unref_dlg( dlg , 1, 0);
return;
}
if (dlg->state!=DLG_STATE_CONFIRMED)
LOG(L_WARN, "WARNING:dialog:dlg_onroute: BYE for "
"unconfirmed dialog ?!\n");
/* dialog terminated (BYE) */
run_dlg_callbacks( DLGCB_TERMINATED, dlg, req);
unref_dlg(dlg, 2, 1);
if_update_stat( dlg_enable_stats, active_dlgs, -1);
return;
} else {
/* within dialog request */
run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req);
}
if (req->first_line.u.request.method_value!=METHOD_ACK) {
dlg->lifetime = get_dlg_timeout(req);
update_dlg_timer( &dlg->tl, dlg->lifetime );
}
unref_dlg( dlg , 1, 0);
return;
}
Andy Pyles wrote:
HI Michel,
Well here's what I'm doing:
if ( loose_route() {
if($DLG_status == 0 && method!="BYE" ){ *** assuming latest patch
accepted
xlog("L_INFO", "broken ua, dropping packet\n");
exit();
}
}
This isn't the most elegant solution, but in my case works ok.
Basically Lets say the UAC is broken. The first opportunity to tell it
is "broken" is when it sends an ACK to the 200 OK.
At this point, it would be very nice to have an option to send "BYE",
but as this functionality isn't there yet, we just reject the ACK, and
eventually the broken UAC will send a bye.
There may be other corner cases as well, but you get the general idea.
Andy
On 2/26/07, Michel Bensoussan <michel(a)extricom.com> wrote:
Hi
"I think the best approach is to force the UAC vendors to align to the
SIP specifications."
Well..... Good luck.
I don't know why but I think if I call and tell them "get back all you
products and upgrade them to align to the SIP specification" they won't
listen to me. But may be I'm wrong.
Any way. I have to deal with it. Do you have some suggestions? What is
the best dialog module version to start with?
I'm not familiar with SIP but I understand that the "To" header won't
change during a session. Is that right? I'm not sure the "CallID" will
be them same in case of re-INVITE.
So I can save the "To" header in the dialog table and check it if the
rm_param is not found.
I'm not sure how to do this.
Andy, If you have some suggestions too...
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support
broken stuff :)....doing dialog matching in traditional way (without
using RR stuff) is very costly and since complete, un-altered RR
mirroring is mandatory by RFC3261, I see no point of doing it
different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have
to handle the case it doesn't correctly mirror the RR header. Can we
base the dialog states on From and To headers? or Callid? I
understand the the rr_param is used for fast dialog matching (dialog
README). Checking dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> looking at the net capture, it seams that the UAS device
> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
> header - it is removing the hdr parameters, mirroring only the URI,
> which is bogus.
>
> regards,
> bogdan
28 Feb
28 Feb
7:44 p.m.
Hi Michel,
only callid matching is not enough - you should also check the tags. In
the mean while, please upload the patch on the tracker. As I said in the
previous email, my only concern is about performance, as you will have
to check all requests and not the only marked for dialog tracking.
regards,
bogdan
Michel Bensoussan wrote:
Hi
If I understand your solution, you don't allow the session. And what
if ($dlg_count != 0) ?
I tried this. It seems to work but I just quick check it.
The key in "Callid" but I'm not sure it is a good choice. Maybe
"To"
is better.
Add the following function in dlg_hash.c:
(based on release 1.1.1)
struct dlg_cell* lookup_dlg_callid(str* callid)
{
struct dlg_cell *dlg;
struct dlg_entry *d_entry;
int i;
if (d_table==0)
goto not_found;
for( i=0 ; i<d_table->size; i++ ) {
d_entry = &(d_table->entries[i]);
dlg_lock( d_table, d_entry);
for( dlg=d_entry->first ; dlg ; dlg=dlg->next ) {
if (!memcmp(dlg->callid.s, callid->s, dlg->callid.len)) {
if (dlg->state==DLG_STATE_DELETED) {
dlg_unlock( d_table, d_entry);
goto not_found;
}
dlg->ref++;
dlg_unlock( d_table, d_entry);
DBG("DEBUG:dialog:lookup_dlg_callid: dialog callid='%.*s' found
on entry %u.%u\n",
callid->len, ZSW(callid->s), dlg->h_id, dlg->h_entry);
return dlg;
}
}
dlg_unlock( d_table, d_entry);
}
not_found:
DBG("DEBUG:dialog:lookup_dlg: no dialog callid='%.*s' found\n",
callid->len, ZSW(callid->s));
return 0;
}
In dlg_handlers.c, modify dlg_onroute() as following:
void dlg_onroute(struct sip_msg* req, str *route_params, void *param)
{
struct dlg_cell *dlg = 0;
str val;
str callid;
int h_entry;
int h_id;
/* If find rm_param do as previously */
if (d_rrb.get_route_param( req, &rr_param, &val) == 0) {
DBG("DEBUG:dialog:dlg_onroute: route param is '%.*s' (len=%d)\n",
val.len, val.s, val.len);
if ( parse_dlg_rr_param( val.s, val.s+val.len, &h_entry, &h_id)<0 )
return;
dlg = lookup_dlg( h_entry, h_id);
if (dlg==0) {
LOG(L_WARN,"WARNING:dialog:dlg_onroute: unable to find dialog\n");
return;
}
}else if (req->callid){
/* If rm_param not found, look for callid */
dlg = lookup_dlg_callid(&req->callid->body);
if (!dlg){
DBG("DEBUG:dialog:dlg_onroute: Callid '%.*s' not found\n",
req->callid->body.len, req->callid->body.s);
return;
}
}
if (use_tight_match) {
if ((!req->callid && parse_headers(req,HDR_CALLID_F,0)<0) ||
!req->callid) {
LOG(L_ERR, "ERROR:dialog:dlg_onroute: bad request or "
"missing CALLID hdr :-/\n");
return;
}
callid = req->callid->body;
trim(&callid);
if (dlg->callid.len!=callid.len ||
strncmp(dlg->callid.s,callid.s,callid.len)!=0) {
LOG(L_WARN,"WARNING:dialog:dlg_onroute: tight matching
failed\n");
return;
}
}
if (req->first_line.u.request.method_value==METHOD_BYE) {
if (remove_dlg_timer(&dlg->tl)!=0) {
unref_dlg( dlg , 1, 0);
return;
}
if (dlg->state!=DLG_STATE_CONFIRMED)
LOG(L_WARN, "WARNING:dialog:dlg_onroute: BYE for "
"unconfirmed dialog ?!\n");
/* dialog terminated (BYE) */
run_dlg_callbacks( DLGCB_TERMINATED, dlg, req);
unref_dlg(dlg, 2, 1);
if_update_stat( dlg_enable_stats, active_dlgs, -1);
return;
} else {
/* within dialog request */
run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req);
}
if (req->first_line.u.request.method_value!=METHOD_ACK) {
dlg->lifetime = get_dlg_timeout(req);
update_dlg_timer( &dlg->tl, dlg->lifetime );
}
unref_dlg( dlg , 1, 0);
return;
}
Andy Pyles wrote:
HI Michel,
Well here's what I'm doing:
if ( loose_route() {
if($DLG_status == 0 && method!="BYE" ){ *** assuming latest patch
accepted
xlog("L_INFO", "broken ua, dropping packet\n");
exit();
}
}
This isn't the most elegant solution, but in my case works ok.
Basically Lets say the UAC is broken. The first opportunity to tell it
is "broken" is when it sends an ACK to the 200 OK.
At this point, it would be very nice to have an option to send "BYE",
but as this functionality isn't there yet, we just reject the ACK, and
eventually the broken UAC will send a bye.
There may be other corner cases as well, but you get the general idea.
Andy
On 2/26/07, Michel Bensoussan <michel(a)extricom.com> wrote:
Hi
"I think the best approach is to force the UAC vendors to align to the
SIP specifications."
Well..... Good luck.
I don't know why but I think if I call and tell them "get back all you
products and upgrade them to align to the SIP specification" they won't
listen to me. But may be I'm wrong.
Any way. I have to deal with it. Do you have some suggestions? What is
the best dialog module version to start with?
I'm not familiar with SIP but I understand that the "To" header won't
change during a session. Is that right? I'm not sure the "CallID" will
be them same in case of re-INVITE.
So I can save the "To" header in the dialog table and check it if the
rm_param is not found.
I'm not sure how to do this.
Andy, If you have some suggestions too...
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support
broken stuff :)....doing dialog matching in traditional way (without
using RR stuff) is very costly and since complete, un-altered RR
mirroring is mandatory by RFC3261, I see no point of doing it
different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
> Hi Bogdan
> I'm agree with you, but we cannot control the UAS devices so we have
> to handle the case it doesn't correctly mirror the RR header. Can we
> base the dialog states on From and To headers? or Callid? I
> understand the the rr_param is used for fast dialog matching (dialog
> README). Checking dialog matching with headers (From, To, ...),
> will consequently slowing the transaction?
>
> Regards,
> Michel.
>
> Bogdan-Andrei Iancu wrote:
>> Hi Michel,
>>
>> looking at the net capture, it seams that the UAS device
>> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
>> header - it is removing the hdr parameters, mirroring only the URI,
>> which is bogus.
>>
>> regards,
>> bogdan
2 Mar
2 Mar
5:40 p.m.
Hi Michel,
Michel Bensoussan wrote:
Hi Bogdan
In dlg_handlers.c, function dlg_onreply(), when updating the To Tag,
there is the following comment:
/* FIXME: this should be sincronized since multiple 200 can be
* sent out */
I have release 1.1.1.
Is multiple 200 OK is supported in newer version?
not yet...there are still thinks
to finish..
What do you mean by "upload the patch on the tracker"? How can I do that?
see on the openser web site..there is a link to tracker. Use the patches
section.
May be it's better to wait for dialog match based
on Callid *and* Tags?
you already did a version based only on callid - if you post
it on
tracker, maybe somebody else will extend it to use tags also.
Thanks and regards,
bogdan
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> only callid matching is not enough - you should also check the tags.
> In the mean while, please upload the patch on the tracker. As I said
> in the previous email, my only concern is about performance, as you
> will have to check all requests and not the only marked for dialog
> tracking.
>
> regards,
> bogdan
>
> Michel Bensoussan wrote:
>> Hi
>> If I understand your solution, you don't allow the session. And what
>> if ($dlg_count != 0) ?
>>
>> I tried this. It seems to work but I just quick check it.
>> The key in "Callid" but I'm not sure it is a good choice. Maybe
"To"
>> is better.
>>
>> Add the following function in dlg_hash.c:
>> (based on release 1.1.1)
>>
>> struct dlg_cell* lookup_dlg_callid(str* callid)
>> {
>> struct dlg_cell *dlg;
>> struct dlg_entry *d_entry;
>> int i;
>>
>> if (d_table==0)
>> goto not_found;
>>
>> for( i=0 ; i<d_table->size; i++ ) {
>>
>> d_entry = &(d_table->entries[i]);
>>
>> dlg_lock( d_table, d_entry);
>>
>> for( dlg=d_entry->first ; dlg ; dlg=dlg->next ) {
>> if (!memcmp(dlg->callid.s, callid->s, dlg->callid.len)) {
>> if (dlg->state==DLG_STATE_DELETED) {
>> dlg_unlock( d_table, d_entry);
>> goto not_found;
>> }
>> dlg->ref++;
>> dlg_unlock( d_table, d_entry);
>> DBG("DEBUG:dialog:lookup_dlg_callid: dialog callid='%.*s'
>> found on entry %u.%u\n",
>> callid->len, ZSW(callid->s), dlg->h_id, dlg->h_entry);
>> return dlg;
>> }
>> }
>>
>> dlg_unlock( d_table, d_entry);
>> }
>>
>> not_found:
>> DBG("DEBUG:dialog:lookup_dlg: no dialog callid='%.*s'
found\n",
>> callid->len, ZSW(callid->s));
>> return 0;
>> }
>>
>>
>> In dlg_handlers.c, modify dlg_onroute() as following:
>>
>> void dlg_onroute(struct sip_msg* req, str *route_params, void *param)
>> {
>> struct dlg_cell *dlg = 0;
>> str val;
>> str callid;
>> int h_entry;
>> int h_id;
>>
>> /* If find rm_param do as previously */
>> if (d_rrb.get_route_param( req, &rr_param, &val) == 0) {
>> DBG("DEBUG:dialog:dlg_onroute: route param is '%.*s'
(len=%d)\n",
>> val.len, val.s, val.len);
>>
>> if ( parse_dlg_rr_param( val.s, val.s+val.len, &h_entry, &h_id)<0
)
>> return;
>>
>> dlg = lookup_dlg( h_entry, h_id);
>> if (dlg==0) {
>> LOG(L_WARN,"WARNING:dialog:dlg_onroute: unable to find
dialog\n");
>> return;
>> }
>> }else if (req->callid){
>> /* If rm_param not found, look for callid */
>> dlg = lookup_dlg_callid(&req->callid->body);
>> if (!dlg){
>> DBG("DEBUG:dialog:dlg_onroute: Callid '%.*s' not
found\n",
>> req->callid->body.len, req->callid->body.s);
>> return;
>> }
>> }
>>
>> if (use_tight_match) {
>> if ((!req->callid && parse_headers(req,HDR_CALLID_F,0)<0)
||
>> !req->callid) {
>> LOG(L_ERR, "ERROR:dialog:dlg_onroute: bad request or "
>> "missing CALLID hdr :-/\n");
>> return;
>> }
>> callid = req->callid->body;
>> trim(&callid);
>> if (dlg->callid.len!=callid.len ||
>> strncmp(dlg->callid.s,callid.s,callid.len)!=0) {
>> LOG(L_WARN,"WARNING:dialog:dlg_onroute: tight matching
>> failed\n");
>> return;
>> }
>> }
>>
>> if (req->first_line.u.request.method_value==METHOD_BYE) {
>> if (remove_dlg_timer(&dlg->tl)!=0) {
>> unref_dlg( dlg , 1, 0);
>> return;
>> }
>> if (dlg->state!=DLG_STATE_CONFIRMED)
>> LOG(L_WARN, "WARNING:dialog:dlg_onroute: BYE for "
>> "unconfirmed dialog ?!\n");
>>
>> /* dialog terminated (BYE) */
>> run_dlg_callbacks( DLGCB_TERMINATED, dlg, req);
>>
>> unref_dlg(dlg, 2, 1);
>> if_update_stat( dlg_enable_stats, active_dlgs, -1);
>> return;
>> } else {
>> /* within dialog request */
>> run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req);
>> }
>>
>> if (req->first_line.u.request.method_value!=METHOD_ACK) {
>> dlg->lifetime = get_dlg_timeout(req);
>> update_dlg_timer( &dlg->tl, dlg->lifetime );
>> }
>>
>> unref_dlg( dlg , 1, 0);
>> return;
>> }
>>
>>
>>
>>
>> Andy Pyles wrote:
>>> HI Michel,
>>>
>>> Well here's what I'm doing:
>>>
>>> if ( loose_route() {
>>> if($DLG_status == 0 && method!="BYE" ){ *** assuming
latest
>>> patch accepted
>>> xlog("L_INFO", "broken ua, dropping packet\n");
>>> exit();
>>> }
>>> }
>>>
>>> This isn't the most elegant solution, but in my case works ok.
>>> Basically Lets say the UAC is broken. The first opportunity to tell it
>>> is "broken" is when it sends an ACK to the 200 OK.
>>> At this point, it would be very nice to have an option to send
"BYE",
>>> but as this functionality isn't there yet, we just reject the ACK, and
>>> eventually the broken UAC will send a bye.
>>>
>>> There may be other corner cases as well, but you get the general idea.
>>>
>>> Andy
>>>
>>>
>>> On 2/26/07, Michel Bensoussan <michel(a)extricom.com> wrote:
>>>> Hi
>>>>
>>>> "I think the best approach is to force the UAC vendors to align to
>>>> the
>>>> SIP specifications."
>>>>
>>>> Well..... Good luck.
>>>> I don't know why but I think if I call and tell them "get back
all
>>>> you
>>>> products and upgrade them to align to the SIP specification" they
>>>> won't
>>>> listen to me. But may be I'm wrong.
>>>>
>>>> Any way. I have to deal with it. Do you have some suggestions?
>>>> What is
>>>> the best dialog module version to start with?
>>>>
>>>> I'm not familiar with SIP but I understand that the "To"
header won't
>>>> change during a session. Is that right? I'm not sure the
"CallID"
>>>> will
>>>> be them same in case of re-INVITE.
>>>> So I can save the "To" header in the dialog table and check it
if the
>>>> rm_param is not found.
>>>> I'm not sure how to do this.
>>>>
>>>> Andy, If you have some suggestions too...
>>>>
>>>> Regards,
>>>> Michel.
>>>>
>>>> Bogdan-Andrei Iancu wrote:
>>>> > Hi Michael,
>>>> >
>>>> > as you give you the same answer as to Andy :) :
>>>> >
>>>> > "To be honest I'm not fan of complicating my life just to
support
>>>> > broken stuff :)....doing dialog matching in traditional way
>>>> (without
>>>> > using RR stuff) is very costly and since complete, un-altered RR
>>>> > mirroring is mandatory by RFC3261, I see no point of doing it
>>>> > different. "
>>>> >
>>>> > I think the best approach is to force the UAC vendors to align
>>>> to the
>>>> > SIP specifications.
>>>> > regards,
>>>> > bogdan
>>>> >
>>>> >
>>>> > Michel Bensoussan wrote:
>>>> >> Hi Bogdan
>>>> >> I'm agree with you, but we cannot control the UAS devices so
we
>>>> have
>>>> >> to handle the case it doesn't correctly mirror the RR
header.
>>>> Can we
>>>> >> base the dialog states on From and To headers? or Callid? I
>>>> >> understand the the rr_param is used for fast dialog matching
>>>> (dialog
>>>> >> README). Checking dialog matching with headers (From, To, ...),
>>>> >> will consequently slowing the transaction?
>>>> >>
>>>> >> Regards,
>>>> >> Michel.
>>>> >>
>>>> >> Bogdan-Andrei Iancu wrote:
>>>> >>> Hi Michel,
>>>> >>>
>>>> >>> looking at the net capture, it seams that the UAS device
>>>> >>> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror
>>>> the RR
>>>> >>> header - it is removing the hdr parameters, mirroring only
the
>>>> URI,
>>>> >>> which is bogus.
>>>> >>>
>>>> >>> regards,
>>>> >>> bogdan
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
>
>
5 Mar
5 Mar
12:17 p.m.
Hi Bogdan
I was on the patch section, but when I try to log in (I guess I need to
log in to add a patch) there is the following message:
Cache Error!
The following error has occured: The request you made has been filted
Generated by tinyproxy (1.6.3)
May be I can send you the patch (I added tags handle)?
I modified 3 files: dlg_handlers.c, dlg_hash.c and dlg_hash.h
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michel,
Michel Bensoussan wrote:
Hi Bogdan
In dlg_handlers.c, function dlg_onreply(), when updating the To Tag,
there is the following comment:
/* FIXME: this should be sincronized since multiple 200
can be
* sent out */
I have release 1.1.1.
Is multiple 200 OK is supported in newer version?
not yet...there are still thinks
to finish..
What do you mean by "upload the patch on the tracker"? How can I do
that?
see on the openser web site..there is a link to tracker. Use the
patches section.
May be it's better to wait for dialog match
based on Callid *and* Tags?
you already did a version based only on callid - if you
post it on
tracker, maybe somebody else will extend it to use tags also.
Thanks and regards,
bogdan
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> only callid matching is not enough - you should also check the tags.
> In the mean while, please upload the patch on the tracker. As I said
> in the previous email, my only concern is about performance, as you
> will have to check all requests and not the only marked for dialog
> tracking.
>
> regards,
> bogdan
>
> Michel Bensoussan wrote:
>> Hi
>> If I understand your solution, you don't allow the session. And
>> what if ($dlg_count != 0) ?
>>
>> I tried this. It seems to work but I just quick check it.
>> The key in "Callid" but I'm not sure it is a good choice. Maybe
>> "To" is better.
>>
>> Add the following function in dlg_hash.c:
>> (based on release 1.1.1)
>>
>> struct dlg_cell* lookup_dlg_callid(str* callid)
>> {
>> struct dlg_cell *dlg;
>> struct dlg_entry *d_entry;
>> int i;
>>
>> if (d_table==0)
>> goto not_found;
>>
>> for( i=0 ; i<d_table->size; i++ ) {
>>
>> d_entry = &(d_table->entries[i]);
>>
>> dlg_lock( d_table, d_entry);
>>
>> for( dlg=d_entry->first ; dlg ; dlg=dlg->next ) {
>> if (!memcmp(dlg->callid.s, callid->s, dlg->callid.len)) {
>> if (dlg->state==DLG_STATE_DELETED) {
>> dlg_unlock( d_table, d_entry);
>> goto not_found;
>> }
>> dlg->ref++;
>> dlg_unlock( d_table, d_entry);
>> DBG("DEBUG:dialog:lookup_dlg_callid: dialog callid='%.*s'
>> found on entry %u.%u\n",
>> callid->len, ZSW(callid->s), dlg->h_id, dlg->h_entry);
>> return dlg;
>> }
>> }
>>
>> dlg_unlock( d_table, d_entry);
>> }
>>
>> not_found:
>> DBG("DEBUG:dialog:lookup_dlg: no dialog callid='%.*s'
found\n",
>> callid->len, ZSW(callid->s));
>> return 0;
>> }
>>
>>
>> In dlg_handlers.c, modify dlg_onroute() as following:
>>
>> void dlg_onroute(struct sip_msg* req, str *route_params, void *param)
>> {
>> struct dlg_cell *dlg = 0;
>> str val;
>> str callid;
>> int h_entry;
>> int h_id;
>>
>> /* If find rm_param do as previously */
>> if (d_rrb.get_route_param( req, &rr_param, &val) == 0) {
>> DBG("DEBUG:dialog:dlg_onroute: route param is '%.*s'
(len=%d)\n",
>> val.len, val.s, val.len);
>>
>> if ( parse_dlg_rr_param( val.s, val.s+val.len, &h_entry, &h_id)<0
)
>> return;
>>
>> dlg = lookup_dlg( h_entry, h_id);
>> if (dlg==0) {
>> LOG(L_WARN,"WARNING:dialog:dlg_onroute: unable to find
>> dialog\n");
>> return;
>> }
>> }else if (req->callid){
>> /* If rm_param not found, look for callid */
>> dlg = lookup_dlg_callid(&req->callid->body);
>> if (!dlg){
>> DBG("DEBUG:dialog:dlg_onroute: Callid '%.*s' not
found\n",
>> req->callid->body.len, req->callid->body.s);
>> return;
>> }
>> }
>>
>> if (use_tight_match) {
>> if ((!req->callid && parse_headers(req,HDR_CALLID_F,0)<0)
||
>> !req->callid) {
>> LOG(L_ERR, "ERROR:dialog:dlg_onroute: bad request or "
>> "missing CALLID hdr :-/\n");
>> return;
>> }
>> callid = req->callid->body;
>> trim(&callid);
>> if (dlg->callid.len!=callid.len ||
>> strncmp(dlg->callid.s,callid.s,callid.len)!=0) {
>> LOG(L_WARN,"WARNING:dialog:dlg_onroute: tight matching
>> failed\n");
>> return;
>> }
>> }
>>
>> if (req->first_line.u.request.method_value==METHOD_BYE) {
>> if (remove_dlg_timer(&dlg->tl)!=0) {
>> unref_dlg( dlg , 1, 0);
>> return;
>> }
>> if (dlg->state!=DLG_STATE_CONFIRMED)
>> LOG(L_WARN, "WARNING:dialog:dlg_onroute: BYE for "
>> "unconfirmed dialog ?!\n");
>>
>> /* dialog terminated (BYE) */
>> run_dlg_callbacks( DLGCB_TERMINATED, dlg, req);
>>
>> unref_dlg(dlg, 2, 1);
>> if_update_stat( dlg_enable_stats, active_dlgs, -1);
>> return;
>> } else {
>> /* within dialog request */
>> run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req);
>> }
>>
>> if (req->first_line.u.request.method_value!=METHOD_ACK) {
>> dlg->lifetime = get_dlg_timeout(req);
>> update_dlg_timer( &dlg->tl, dlg->lifetime );
>> }
>>
>> unref_dlg( dlg , 1, 0);
>> return;
>> }
>>
>>
>>
>>
>> Andy Pyles wrote:
>>> HI Michel,
>>>
>>> Well here's what I'm doing:
>>>
>>> if ( loose_route() {
>>> if($DLG_status == 0 && method!="BYE" ){ *** assuming
latest
>>> patch accepted
>>> xlog("L_INFO", "broken ua, dropping packet\n");
>>> exit();
>>> }
>>> }
>>>
>>> This isn't the most elegant solution, but in my case works ok.
>>> Basically Lets say the UAC is broken. The first opportunity to
>>> tell it
>>> is "broken" is when it sends an ACK to the 200 OK.
>>> At this point, it would be very nice to have an option to send
"BYE",
>>> but as this functionality isn't there yet, we just reject the ACK,
>>> and
>>> eventually the broken UAC will send a bye.
>>>
>>> There may be other corner cases as well, but you get the general
>>> idea.
>>>
>>> Andy
>>>
>>>
>>> On 2/26/07, Michel Bensoussan <michel(a)extricom.com> wrote:
>>>> Hi
>>>>
>>>> "I think the best approach is to force the UAC vendors to align
>>>> to the
>>>> SIP specifications."
>>>>
>>>> Well..... Good luck.
>>>> I don't know why but I think if I call and tell them "get back
>>>> all you
>>>> products and upgrade them to align to the SIP specification" they
>>>> won't
>>>> listen to me. But may be I'm wrong.
>>>>
>>>> Any way. I have to deal with it. Do you have some suggestions?
>>>> What is
>>>> the best dialog module version to start with?
>>>>
>>>> I'm not familiar with SIP but I understand that the "To"
header
>>>> won't
>>>> change during a session. Is that right? I'm not sure the
"CallID"
>>>> will
>>>> be them same in case of re-INVITE.
>>>> So I can save the "To" header in the dialog table and check it
if
>>>> the
>>>> rm_param is not found.
>>>> I'm not sure how to do this.
>>>>
>>>> Andy, If you have some suggestions too...
>>>>
>>>> Regards,
>>>> Michel.
>>>>
>>>> Bogdan-Andrei Iancu wrote:
>>>> > Hi Michael,
>>>> >
>>>> > as you give you the same answer as to Andy :) :
>>>> >
>>>> > "To be honest I'm not fan of complicating my life just to
support
>>>> > broken stuff :)....doing dialog matching in traditional way
>>>> (without
>>>> > using RR stuff) is very costly and since complete, un-altered RR
>>>> > mirroring is mandatory by RFC3261, I see no point of doing it
>>>> > different. "
>>>> >
>>>> > I think the best approach is to force the UAC vendors to align
>>>> to the
>>>> > SIP specifications.
>>>> > regards,
>>>> > bogdan
>>>> >
>>>> >
>>>> > Michel Bensoussan wrote:
>>>> >> Hi Bogdan
>>>> >> I'm agree with you, but we cannot control the UAS devices so
>>>> we have
>>>> >> to handle the case it doesn't correctly mirror the RR
header.
>>>> Can we
>>>> >> base the dialog states on From and To headers? or Callid? I
>>>> >> understand the the rr_param is used for fast dialog matching
>>>> (dialog
>>>> >> README). Checking dialog matching with headers (From, To, ...),
>>>> >> will consequently slowing the transaction?
>>>> >>
>>>> >> Regards,
>>>> >> Michel.
>>>> >>
>>>> >> Bogdan-Andrei Iancu wrote:
>>>> >>> Hi Michel,
>>>> >>>
>>>> >>> looking at the net capture, it seams that the UAS device
>>>> >>> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror
>>>> the RR
>>>> >>> header - it is removing the hdr parameters, mirroring only
>>>> the URI,
>>>> >>> which is bogus.
>>>> >>>
>>>> >>> regards,
>>>> >>> bogdan
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
>
>
5:49 p.m.
Hi Michel,
just send the patch (unified format) to me and I will upload it on tracker.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I was on the patch section, but when I try to log in (I guess I need
to log in to add a patch) there is the following message:
Cache Error!
The following error has occured: The request you made has been filted
Generated by tinyproxy (1.6.3)
May be I can send you the patch (I added tags handle)?
I modified 3 files: dlg_handlers.c, dlg_hash.c and dlg_hash.h
6:22 p.m.
Hi Bogdan.
Find attached the files dlg_handlers.c, dlg_hash.c and dlg_hash.h.
In dlg_handlers.c, I modified the function dlg_onroute() as following:
if (find rr_param) { do as previous }
else {look for matching callid and tags}
In dlg_hash.c, I add the static functions get_to_tag() and
get_from_tag() (copied from nathelper.c) and the function get_dlg().
I start from revision 1.1.1.
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michel,
just send the patch (unified format) to me and I will upload it on
tracker.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I was on the patch section, but when I try to log in (I guess I need
to log in to add a patch) there is the following message:
Cache Error!
The following error has occured: The request you made has been filted
Generated by tinyproxy (1.6.3)
May be I can send you the patch (I added tags handle)?
I modified 3 files: dlg_handlers.c, dlg_hash.c and dlg_hash.h
9 Mar
9 Mar
12:03 p.m.
Hi Michel
I created a new patch submission (id 1677092).
Thanks and regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan.
Find attached the files dlg_handlers.c, dlg_hash.c and dlg_hash.h.
In dlg_handlers.c, I modified the function dlg_onroute() as following:
if (find rr_param) { do as previous }
else {look for matching callid and tags}
In dlg_hash.c, I add the static functions get_to_tag() and
get_from_tag() (copied from nathelper.c) and the function get_dlg().
I start from revision 1.1.1.
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> just send the patch (unified format) to me and I will upload it on
> tracker.
>
> regards,
> bogdan
>
> Michel Bensoussan wrote:
>> Hi Bogdan
>> I was on the patch section, but when I try to log in (I guess I need
>> to log in to add a patch) there is the following message:
>> Cache Error!
>> The following error has occured: The request you made has been
>> filted
>> Generated by tinyproxy (1.6.3)
>>
>> May be I can send you the patch (I added tags handle)?
>> I modified 3 files: dlg_handlers.c, dlg_hash.c and dlg_hash.h
>>
>
>
>
11 Mar
11 Mar
1:27 p.m.
Hi Bogdan
Thank you but the matching is based on callid AND tags (to and from).
Regards
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michel
I created a new patch submission (id 1677092).
Thanks and regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan.
Find attached the files dlg_handlers.c, dlg_hash.c and dlg_hash.h.
In dlg_handlers.c, I modified the function dlg_onroute() as following:
if (find rr_param) { do as previous }
else {look for matching callid and tags}
In dlg_hash.c, I add the static functions get_to_tag() and
get_from_tag() (copied from nathelper.c) and the function get_dlg().
I start from revision 1.1.1.
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> just send the patch (unified format) to me and I will upload it on
> tracker.
>
> regards,
> bogdan
>
> Michel Bensoussan wrote:
>> Hi Bogdan
>> I was on the patch section, but when I try to log in (I guess I
>> need to log in to add a patch) there is the following message:
>> Cache Error!
>> The following error has occured: The request you made has been
>> filted
>> Generated by tinyproxy (1.6.3)
>>
>> May be I can send you the patch (I added tags handle)?
>> I modified 3 files: dlg_handlers.c, dlg_hash.c and dlg_hash.h
>>
>
>
>
14 Mar
14 Mar
1:57 p.m.
Hi Michel,
sorry - I was not aware you already added TAG matching support. I will
take a look at it.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
Thank you but the matching is based on callid AND tags (to and from).
Regards
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michel
I created a new patch submission (id 1677092).
Thanks and regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan.
Find attached the files dlg_handlers.c, dlg_hash.c and dlg_hash.h.
In dlg_handlers.c, I modified the function dlg_onroute() as following:
if (find rr_param) { do as previous }
else {look for matching callid and tags}
In dlg_hash.c, I add the static functions get_to_tag() and
get_from_tag() (copied from nathelper.c) and the function get_dlg().
I start from revision 1.1.1.
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> just send the patch (unified format) to me and I will upload it on
> tracker.
>
> regards,
> bogdan
>
> Michel Bensoussan wrote:
>> Hi Bogdan
>> I was on the patch section, but when I try to log in (I guess I
>> need to log in to add a patch) there is the following message:
>> Cache Error!
>> The following error has occured: The request you made has been
>> filted
>> Generated by tinyproxy (1.6.3)
>>
>> May be I can send you the patch (I added tags handle)?
>> I modified 3 files: dlg_handlers.c, dlg_hash.c and dlg_hash.h
>>
>
>
>
6 Mar
6 Mar
11:16 a.m.
Hi Michel,
the documented races were fixed in the latest SVN trunk version.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
In dlg_handlers.c, function dlg_onreply(), when updating the To Tag,
there is the following comment:
/* FIXME: this should be sincronized since multiple 200 can be
* sent out */
I have release 1.1.1.
Is multiple 200 OK is supported in newer version?
2 Mar
2 Mar
5:38 p.m.
Hi Andy,
the patch was accepted, but if no dialog is matched, NULL value is
returned by related pseudo vars. So try:
f($DLG_status == NULL && method!="BYE" ){}
regards,
bogdan
Andy Pyles wrote:
HI Michel,
Well here's what I'm doing:
if ( loose_route() {
if($DLG_status == 0 && method!="BYE" ){ *** assuming latest patch
accepted
xlog("L_INFO", "broken ua, dropping packet\n");
exit();
}
}
This isn't the most elegant solution, but in my case works ok.
Basically Lets say the UAC is broken. The first opportunity to tell it
is "broken" is when it sends an ACK to the 200 OK.
At this point, it would be very nice to have an option to send "BYE",
but as this functionality isn't there yet, we just reject the ACK, and
eventually the broken UAC will send a bye.
There may be other corner cases as well, but you get the general idea.
Andy
On 2/26/07, Michel Bensoussan <michel(a)extricom.com> wrote:
Hi
"I think the best approach is to force the UAC vendors to align to the
SIP specifications."
Well..... Good luck.
I don't know why but I think if I call and tell them "get back all you
products and upgrade them to align to the SIP specification" they won't
listen to me. But may be I'm wrong.
Any way. I have to deal with it. Do you have some suggestions? What is
the best dialog module version to start with?
I'm not familiar with SIP but I understand that the "To" header won't
change during a session. Is that right? I'm not sure the "CallID" will
be them same in case of re-INVITE.
So I can save the "To" header in the dialog table and check it if the
rm_param is not found.
I'm not sure how to do this.
Andy, If you have some suggestions too...
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support
broken stuff :)....doing dialog matching in traditional way (without
using RR stuff) is very costly and since complete, un-altered RR
mirroring is mandatory by RFC3261, I see no point of doing it
different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have
to handle the case it doesn't correctly mirror the RR header. Can we
base the dialog states on From and To headers? or Callid? I
understand the the rr_param is used for fast dialog matching (dialog
README). Checking dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> looking at the net capture, it seams that the UAS device
> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
> header - it is removing the hdr parameters, mirroring only the URI,
> which is bogus.
>
> regards,
> bogdan
28 Feb
28 Feb
7:38 p.m.
Hi Michel,
my opinion is based on the following thinking. To solve your problem,
there are 2 ways:
1) approach openser developers to fix dialog module to cope with
bugy clients. The result will be something outside the RFC specs and
with a lot of penalties (note that the RR param is not only used for the
dialog matching but also for identifying what dialogs are monitored -
you can have dialog state only for calls going to PSTN for example and
you should not try process/match requests for the rest the calls)
2) approach the UAC vendors to fix the bug in their firmware. The
result is something full RFC compliant and with no penalties.
As I see, in both cases it is about approaching somebody for doing a
fix, but the outcome is different :)....
regards,
bogdan
Michel Bensoussan wrote:
Hi
"I think the best approach is to force the UAC vendors to align to the
SIP specifications."
Well..... Good luck.
I don't know why but I think if I call and tell them "get back all you
products and upgrade them to align to the SIP specification" they
won't listen to me. But may be I'm wrong.
Any way. I have to deal with it. Do you have some suggestions? What is
the best dialog module version to start with?
I'm not familiar with SIP but I understand that the "To" header won't
change during a session. Is that right? I'm not sure the "CallID" will
be them same in case of re-INVITE.
So I can save the "To" header in the dialog table and check it if the
rm_param is not found.
I'm not sure how to do this.
Andy, If you have some suggestions too...
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
Hi Michael,
as you give you the same answer as to Andy :) :
"To be honest I'm not fan of complicating my life just to support
broken stuff :)....doing dialog matching in traditional way (without
using RR stuff) is very costly and since complete, un-altered RR
mirroring is mandatory by RFC3261, I see no point of doing it
different. "
I think the best approach is to force the UAC vendors to align to the
SIP specifications.
regards,
bogdan
Michel Bensoussan wrote:
Hi Bogdan
I'm agree with you, but we cannot control the UAS devices so we have
to handle the case it doesn't correctly mirror the RR header. Can we
base the dialog states on From and To headers? or Callid? I
understand the the rr_param is used for fast dialog matching (dialog
README). Checking dialog matching with headers (From, To, ...),
will consequently slowing the transaction?
Regards,
Michel.
Bogdan-Andrei Iancu wrote:
> Hi Michel,
>
> looking at the net capture, it seams that the UAS device
> (User-Agent: WLAN660-S VoIP PHONE) does not correctly mirror the RR
> header - it is removing the hdr parameters, mirroring only the URI,
> which is bogus.
>
> regards,
> bogdan
27 Feb
27 Feb
9:23 a.m.
Michel Bensoussan writes:
I'm agree with you, but we cannot control the UAS
devices so we have to
handle the case it doesn't correctly mirror the RR header.
why is that? you simply say that those UAS are not SIP compliant and
you don't support them. whoever has bought such devices can paint them
green and sink to sea. once you start implementing hack to deal with
non-SIP devices, there is no limit how far you would need to go.
-- juha
9:29 a.m.
Hi,
* Juha Heinanen <jh(a)tutpro.com> [070227 08:26]:
Michel Bensoussan writes:
I have'nt followed the discussion, but I tend to agree with your last
statement to a point. There are alot of Sip-devices that does'nt do sip
correct, and if you would exclude all of them.. how working sip-devices
would there be left? Some hacks are ok in my opinion, but dont overdo
it.
-Atle
I'm agree with you, but we cannot control the
UAS devices so we have to
handle the case it doesn't correctly mirror the RR header.
why is that? you simply say that those UAS are not SIP compliant and
you don't support them. whoever has bought such devices can paint them
green and sink to sea. once you start implementing hack to deal with
non-SIP devices, there is no limit how far you would need to go.
-- juha
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:05 a.m.
Hi Juha,
Well, this is a commercial issue.
You can not tell to your client "If you take our product you cannot use...".
It always happens. For example there are Bluetooth devices or Wifi
devices that are very common but there are not completely implement the
standard.
You cannot propose an Access Point that cannot associates with NetGear,
even if NetGear have some bugs regarding the 802.11 implementation.
Unless you are Intel... :-)
Regards,
Michel.
Juha Heinanen wrote:
Michel Bensoussan writes:
I'm agree with you, but we cannot control the
UAS devices so we have to
handle the case it doesn't correctly mirror the RR header.
why is that? you simply say that those UAS are not SIP compliant and
you don't support them. whoever has bought such devices can paint them
green and sink to sea. once you start implementing hack to deal with
non-SIP devices, there is no limit how far you would need to go.
-- juha
6466
days inactive
6488
days old
29 comments
5 participants
participants (5)
-
Andy Pyles -
Atle Samuelsen -
Bogdan-Andrei Iancu -
Juha Heinanen -
Michel Bensoussan