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
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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
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@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@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@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@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 >
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@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@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@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
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
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@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
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@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
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@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
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@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
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@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 > > >
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
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
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
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
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
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?
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@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
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
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
Hi,
* Juha Heinanen jh@tutpro.com [070227 08:26]:
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.
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
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
-
Andy Pyles -
Atle Samuelsen -
Bogdan-Andrei Iancu -
Juha Heinanen -
Michel Bensoussan