thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back since the CANCEL was not send out to the terminating UA by SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles CANCEL {other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
I am having a similar problem. I am not yet convinced that it is SER as much as my configuration but if SER does have difficulty processing CANCEL messages it would be helpful to understand under what circumstances.
By the way I have been using t_check_status in
a
similar way since v 0.8 code. When I upgraded to 0.9.0, .0 and now
.2
the t_check_status fails to be matched.
-Steve
Thanks,Steve
a c wrote:
any ideas anyone? seems like SER does not respond
to
CANCEL requests and eventually takes the failure route.
I have the following in my failure route, but it
never
gets hit, since SER does not send the 200 OK back
or
pass the CANCEL message forward. log file
attached.
failure_route[1] { if(t_check_status("487")) { # don't continue on cancellation xlog("L_WARN", "OH OH OH\n"); break; }
ac
--- a c lra101@yahoo.com wrote:
Seems like SER does not respond back to CANCEL Requests. Is this a issue / some config problem
on
my side? ngrep traces attached
interface: eth0 (192.168.0.0/255.255.255.0) filter: ip and ( port 5060 ) # U 192.168.0.2:5062 -> 192.168.0.5:5060 INVITE sip:9999999999@voip.com SIP/2.0..Via: SIP/2.0/UDP 192.168.0.2:5062;r
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
102 <sip:102@voi p.com:5062>;tag=3282942385..To: sip:9999999999@voip.com..Contact: <sip:10 2@192.168.0.2:5062>..Call-ID: 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. 0.2..CSeq: 940 INVITE..Max-Forwards: 70..Content-Type: application/sdp..Use r-Agent: X-Lite release 1103m..Content-Length: 258....v=0..o=102 7659613 76 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 192.168.0.2..t=0 0..m=audio 80 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma p:3 gsm/8000..a=rtpmap:98
iLBC/8000..a=rtpmap:96
telephone-event/8000..a=fm tp:96 0-15..
# U 192.168.0.5:5060 -> 192.168.0.2:5062 SIP/2.0 100 trying -- your call is important
to
us..Via: SIP/2.0/UDP 192.16
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
102
sip:102@voip.com:5062;tag=3282942385..To:
sip:9999999999@voip.com. .Call-ID:
29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168.0.2..CSeq:
940 INVIT E..Server: Sip EXpress router (0.9.2 (i386/linux))..Content-Length: 0..Warn ing: 392 192.168.0.5:5060 "Noisy feedback
tells:
pid=2943 req_src_ip=192.1 68.0.2 req_src_port=5062 in_uri=sip:9999999999@voip.com
out_uri=sip:9999999
999@voip.com via_cnt==1"....
# U 192.168.0.5:5060 -> 192.168.0.3:5060 INVITE sip:9999999999@voip.com SIP/2.0..Record-Route: <sip:192.168.0.5;ftag =3282942385;lr=on>..Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bKe034.1018c5d 1.0..Via: SIP/2.0/UDP
192.168.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8C
F4A479B6D9DDB17C5CFC1..From: 102 sip:102@voip.com:5062;tag=3282942385..To : sip:9999999999@voip.com..Contact: sip:102@192.168.0.2:5062..Call-ID:
29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168.0.2..CSeq:
940 INVITE..Max-For wards: 16..Content-Type: application/sdp..User-Agent: X-Lite release
1103m.
.Content-Length: 258....v=0..o=102 7659613
7659633
IN IP4 192.168.0.2..s=X- Lite..c=IN IP4 192.168.0.2..t=0 0..m=audio
8000
RTP/AVP 0 8 3 98 96..a=rtpm ap:0 pcmu/8000..a=rtpmap:8
pcma/8000..a=rtpmap:3
gsm/8000..a=rtpmap:98 iLBC /8000..a=rtpmap:96
telephone-event/8000..a=fmtp:96
0-15.. # U 192.168.0.3:5060 -> 192.168.0.5:5060 SIP/2.0 100 Trying..From: 102 sip:102@voip.com:5062;tag=3282942385..To: < sip:9999999999@voip.com>..Call-Id: 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192 .168.0.2..Cseq: 940 INVITE..Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bKe034 .1018c5d1.0..Via: SIP/2.0/UDP 192.168.0.2:5062;rport=5062;branch=z9hG4bKE29 503D9D8CF4A479B6D9DDB17C5CFC1..Content-Length: 0....
# U 192.168.0.3:5060 -> 192.168.0.5:5060 SIP/2.0 180 Ringing..From: 102
=== message truncated ===
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back since the CANCEL was not send out to the terminating UA by SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles CANCEL {other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
I am having a similar problem. I am not yet convinced that it is SER as much as my configuration but if SER does have difficulty processing CANCEL messages it would be helpful to understand under what circumstances.
By the way I have been using t_check_status in
a
similar way since v 0.8 code. When I upgraded to 0.9.0, .0 and now
.2
the t_check_status fails to be matched.
-Steve
Thanks,Steve
a c wrote:
any ideas anyone? seems like SER does not respond
to
CANCEL requests and eventually takes the failure route.
I have the following in my failure route, but it
never
gets hit, since SER does not send the 200 OK back
or
pass the CANCEL message forward. log file
attached.
failure_route[1] { if(t_check_status("487")) { # don't continue on cancellation xlog("L_WARN", "OH OH OH\n"); break; }
ac
--- a c lra101@yahoo.com wrote:
Seems like SER does not respond back to CANCEL Requests. Is this a issue / some config problem
on
my side? ngrep traces attached
interface: eth0 (192.168.0.0/255.255.255.0) filter: ip and ( port 5060 ) # U 192.168.0.2:5062 -> 192.168.0.5:5060 INVITE sip:9999999999@voip.com SIP/2.0..Via: SIP/2.0/UDP 192.168.0.2:5062;r
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
102 sip:102@voi p.com:5062;tag=3282942385..To: sip:9999999999@voip.com..Contact: sip:10 2@192.168.0.2:5062..Call-ID: 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. 0.2..CSeq: 940 INVITE..Max-Forwards: 70..Content-Type: application/sdp..Use r-Agent: X-Lite release 1103m..Content-Length: 258....v=0..o=102 7659613 76 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 192.168.0.2..t=0 0..m=audio 80 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma p:3 gsm/8000..a=rtpmap:98
iLBC/8000..a=rtpmap:96
telephone-event/8000..a=fm tp:96 0-15..
# U 192.168.0.5:5060 -> 192.168.0.2:5062 SIP/2.0 100 trying -- your call is important
to
us..Via: SIP/2.0/UDP 192.16
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
102
sip:102@voip.com:5062;tag=3282942385..To:
sip:9999999999@voip.com. .Call-ID:
29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168.0.2..CSeq:
940 INVIT E..Server: Sip EXpress router (0.9.2 (i386/linux))..Content-Length: 0..Warn ing: 392 192.168.0.5:5060 "Noisy feedback
tells:
pid=2943 req_src_ip=192.1 68.0.2 req_src_port=5062 in_uri=sip:9999999999@voip.com
out_uri=sip:9999999
999@voip.com via_cnt==1"....
# U 192.168.0.5:5060 -> 192.168.0.3:5060 INVITE sip:9999999999@voip.com SIP/2.0..Record-Route: sip:192.168.0.5;ftag =3282942385;lr=on..Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bKe034.1018c5d 1.0..Via: SIP/2.0/UDP
192.168.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8C
F4A479B6D9DDB17C5CFC1..From: 102 sip:102@voip.com:5062;tag=3282942385..To : sip:9999999999@voip.com..Contact: sip:102@192.168.0.2:5062..Call-ID:
29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168.0.2..CSeq:
940 INVITE..Max-For wards: 16..Content-Type: application/sdp..User-Agent: X-Lite release
1103m.
.Content-Length: 258....v=0..o=102 7659613
7659633
IN IP4 192.168.0.2..s=X- Lite..c=IN IP4 192.168.0.2..t=0 0..m=audio
8000
RTP/AVP 0 8 3 98 96..a=rtpm ap:0 pcmu/8000..a=rtpmap:8
pcma/8000..a=rtpmap:3
gsm/8000..a=rtpmap:98 iLBC /8000..a=rtpmap:96
telephone-event/8000..a=fmtp:96
0-15.. # U 192.168.0.3:5060 -> 192.168.0.5:5060 SIP/2.0 100 Trying..From: 102 sip:102@voip.com:5062;tag=3282942385..To: < sip:9999999999@voip.com>..Call-Id: 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192 .168.0.2..Cseq: 940 INVITE..Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bKe034 .1018c5d1.0..Via: SIP/2.0/UDP 192.168.0.2:5062;rport=5062;branch=z9hG4bKE29 503D9D8CF4A479B6D9DDB17C5CFC1..Content-Length: 0....
# U 192.168.0.3:5060 -> 192.168.0.5:5060 SIP/2.0 180 Ringing..From: 102
=== message truncated ===
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
main route block..ac
# main routing logic route{
if (method == "CANCEL"){ t_relay(); } ...
--- Steve Blair blairs@isc.upenn.edu wrote:
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not
have
this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back
since
the CANCEL was not send out to the terminating UA
by
SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles
CANCEL
{other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
I am having a similar problem. I am not yet convinced that it is SER as much as my configuration but if SER does have difficulty processing CANCEL messages it would be helpful to understand under what circumstances.
By the way I have been using t_check_status in
a
similar way since v 0.8 code. When I upgraded to 0.9.0, .0 and now
.2
the t_check_status fails to be matched.
-Steve
Thanks,Steve
a c wrote:
any ideas anyone? seems like SER does not
respond
to
CANCEL requests and eventually takes the failure route.
I have the following in my failure route, but it
never
gets hit, since SER does not send the 200 OK
back
or
pass the CANCEL message forward. log file
attached.
failure_route[1] { if(t_check_status("487")) { # don't continue on cancellation xlog("L_WARN", "OH OH OH\n"); break; }
ac
--- a c lra101@yahoo.com wrote:
Seems like SER does not respond back to CANCEL Requests. Is this a issue / some config problem
on
my side? ngrep traces attached
interface: eth0 (192.168.0.0/255.255.255.0) filter: ip and ( port 5060 ) # U 192.168.0.2:5062 -> 192.168.0.5:5060 INVITE sip:9999999999@voip.com SIP/2.0..Via: SIP/2.0/UDP 192.168.0.2:5062;r
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
102 sip:102@voi p.com:5062;tag=3282942385..To: sip:9999999999@voip.com..Contact: sip:10 2@192.168.0.2:5062..Call-ID: 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. 0.2..CSeq: 940 INVITE..Max-Forwards: 70..Content-Type: application/sdp..Use r-Agent: X-Lite release 1103m..Content-Length: 258....v=0..o=102 7659613 76 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 192.168.0.2..t=0 0..m=audio 80 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma p:3 gsm/8000..a=rtpmap:98
iLBC/8000..a=rtpmap:96
telephone-event/8000..a=fm tp:96 0-15..
# U 192.168.0.5:5060 -> 192.168.0.2:5062 SIP/2.0 100 trying -- your call is important
to
us..Via: SIP/2.0/UDP 192.16
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
102
sip:102@voip.com:5062;tag=3282942385..To:
sip:9999999999@voip.com. .Call-ID:
=== message truncated ===
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
A part of the ONsip.org Getting Started effort is to make configuration files that can be used as a reference (and thus should be validated for correctness through theory and scrutiny from community). CANCELs can be in dialog and outside dialog and must thus be handled in two ways. In dialog they should be handled through the loose route (and basically t_relay'ed), while outside dialog they should be handled as INVITEs (credits go to Jan for explaining this in detail). Ex. this configuration file will show you this: http://www.onsip.org/modules/mydownloads/viewcat.php?cid=7
g-)
a c wrote:
main route block..ac
# main routing logic route{
if (method == "CANCEL"){ t_relay(); }
...
--- Steve Blair blairs@isc.upenn.edu wrote:
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back since the CANCEL was not send out to the terminating UA by SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles CANCEL {other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
I am having a similar problem. I am not yet convinced that it is SER as much as my configuration but if SER does have difficulty processing CANCEL messages it would be helpful to understand under what circumstances.
By the way I have been using t_check_status in
a
similar way since v 0.8 code. When I upgraded to 0.9.0, .0 and now
.2
the t_check_status fails to be matched.
-Steve
Thanks,Steve
a c wrote:
any ideas anyone? seems like SER does not respond
to
CANCEL requests and eventually takes the failure route.
I have the following in my failure route, but it
never
gets hit, since SER does not send the 200 OK back
or
pass the CANCEL message forward. log file
attached.
failure_route[1] { if(t_check_status("487")) { # don't continue on cancellation xlog("L_WARN", "OH OH OH\n"); break; }
ac
--- a c lra101@yahoo.com wrote:
> Seems like SER does not respond back to CANCEL > Requests. Is this a issue / some config problem > >
on
> my > side? ngrep traces attached > > interface: eth0 (192.168.0.0/255.255.255.0) > filter: ip and ( port 5060 ) > # > U 192.168.0.2:5062 -> 192.168.0.5:5060 > INVITE sip:9999999999@voip.com SIP/2.0..Via: > SIP/2.0/UDP 192.168.0.2:5062;r > > > > > >
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> 102 sip:102@voi p.com:5062>;tag=3282942385..To: > sip:9999999999@voip.com..Contact: sip:10 2@192.168.0.2:5062>..Call-ID: > 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. > 0.2..CSeq: 940 INVITE..Max-Forwards: > 70..Content-Type: application/sdp..Use > r-Agent: X-Lite release 1103m..Content-Length: > 258....v=0..o=102 7659613 76 > 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 > 192.168.0.2..t=0 0..m=audio 80 > 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 > pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma > p:3 gsm/8000..a=rtpmap:98 > >
iLBC/8000..a=rtpmap:96
> telephone-event/8000..a=fm > tp:96 0-15.. > >
> > # > U 192.168.0.5:5060 -> 192.168.0.2:5062 > SIP/2.0 100 trying -- your call is important > >
to
> us..Via: SIP/2.0/UDP 192.16 > > > > > >
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> 102 > >
sip:102@voip.com:5062;tag=3282942385..To:
> sip:9999999999@voip.com. > .Call-ID: > >
=== message truncated ===
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greger V. Teigre wrote:
A part of the ONsip.org Getting Started effort is to make configuration files that can be used as a reference (and thus should be validated for correctness through theory and scrutiny from community). CANCELs can be in dialog and outside dialog and must thus be handled in two ways. In dialog they should be handled through the loose route (and basically t_relay'ed), while outside dialog they should be handled as INVITEs (credits go to Jan for explaining this in detail). Ex. this configuration file will show you this: http://www.onsip.org/modules/mydownloads/viewcat.php?cid=7
While this link is not accessible I appreciate the explanation.
Thanks.
g-)
a c wrote:
main route block..ac
# main routing logic route{
if (method == "CANCEL"){ t_relay(); }
...
--- Steve Blair blairs@isc.upenn.edu wrote:
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back since the CANCEL was not send out to the terminating UA by SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles CANCEL {other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
I am having a similar problem. I am not yet convinced that it is SER as much as my configuration but if SER does have difficulty processing CANCEL messages it would be helpful to understand under what circumstances.
By the way I have been using t_check_status in
a
similar way since v 0.8 code. When I upgraded to 0.9.0, .0 and now
.2
the t_check_status fails to be matched.
-Steve
Thanks,Steve
a c wrote:
> any ideas anyone? seems like SER does not respond > > to
> CANCEL requests and eventually takes the failure > route. > > I have the following in my failure route, but it > > never
> gets hit, since SER does not send the 200 OK back > > or
> pass the CANCEL message forward. log file > >
attached.
> failure_route[1] > { > if(t_check_status("487")) { > # don't continue on cancellation > xlog("L_WARN", "OH OH OH\n"); > break; > } > > ac > > > --- a c lra101@yahoo.com wrote: > > > > > >> Seems like SER does not respond back to CANCEL >> Requests. Is this a issue / some config problem >> >>
on
>> my >> side? ngrep traces attached >> >> interface: eth0 (192.168.0.0/255.255.255.0) >> filter: ip and ( port 5060 ) >> # >> U 192.168.0.2:5062 -> 192.168.0.5:5060 >> INVITE sip:9999999999@voip.com SIP/2.0..Via: >> SIP/2.0/UDP 192.168.0.2:5062;r >> >> >> >> >> >>
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> > > > >> 102 sip:102@voi > p.com:5062>;tag=3282942385..To: >> sip:9999999999@voip.com..Contact: sip:10 > 2@192.168.0.2:5062>..Call-ID: >> 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. >> 0.2..CSeq: 940 INVITE..Max-Forwards: >> 70..Content-Type: application/sdp..Use >> r-Agent: X-Lite release 1103m..Content-Length: >> 258....v=0..o=102 7659613 76 >> 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 >> 192.168.0.2..t=0 0..m=audio 80 >> 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 >> pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma >> p:3 gsm/8000..a=rtpmap:98 >> >>
iLBC/8000..a=rtpmap:96
>> telephone-event/8000..a=fm >> tp:96 0-15.. >> >>
>> >> # >> U 192.168.0.5:5060 -> 192.168.0.2:5062 >> SIP/2.0 100 trying -- your call is important >> >>
to
>> us..Via: SIP/2.0/UDP 192.16 >> >> >> >> >> >>
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> > > > >> 102 >> >>
sip:102@voip.com:5062;tag=3282942385..To:
>> sip:9999999999@voip.com. >> .Call-ID: >> >>
=== message truncated ===
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
hello,
having some problems loading the mysql module. I am using the latest dev release. couldn't find much help in the archieves..
ser -cf ser.mysql.cfg 0(1439) ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: /usr/local/lib/ser/modules/mysql.so: undefined symbol: fm_malloc 0(1439) parse error (15,13-14): failed to load module ERROR: bad config file (1 errors)
----------------config------------------ debug=3 fork=yes log_stderror=no
listen=192.168.0.5 port=5060 children=4
dns=no rev_dns=no
fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Looks like you have compiled with a memory alloc function not available. Check your Makefile.defs file. There are many different options. Look at this section: DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ -DDBG_QM_MALLOC \ -DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
You can comment out F_MALLOC g-)
a c wrote:
hello,
having some problems loading the mysql module. I am using the latest dev release. couldn't find much help in the archieves..
ser -cf ser.mysql.cfg 0(1439) ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: /usr/local/lib/ser/modules/mysql.so: undefined symbol: fm_malloc 0(1439) parse error (15,13-14): failed to load module ERROR: bad config file (1 errors)
----------------config------------------ debug=3 fork=yes log_stderror=no
listen=192.168.0.5 port=5060 children=4
dns=no rev_dns=no
fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
hello Greger,
seems like it is already commented out..hmm
DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ #-DDBG_QM_MALLOC \ #-DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
--- "Greger V. Teigre" greger@teigre.com wrote:
Looks like you have compiled with a memory alloc function not available. Check your Makefile.defs file. There are many different options. Look at this section: DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ -DDBG_QM_MALLOC \ -DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
You can comment out F_MALLOC g-)
a c wrote:
hello,
having some problems loading the mysql module. I
am
using the latest dev release. couldn't find much
help
in the archieves..
ser -cf ser.mysql.cfg 0(1439) ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: /usr/local/lib/ser/modules/mysql.so: undefined
symbol:
fm_malloc 0(1439) parse error (15,13-14): failed to load
module
ERROR: bad config file (1 errors)
----------------config------------------ debug=3 fork=yes log_stderror=no
listen=192.168.0.5 port=5060 children=4
dns=no rev_dns=no
fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
I would check one more time and make sure that compilation and linking give no errors/warnings... g-)
a c wrote:
hello Greger,
seems like it is already commented out..hmm
DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ #-DDBG_QM_MALLOC \ #-DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
--- "Greger V. Teigre" greger@teigre.com wrote:
Looks like you have compiled with a memory alloc function not available. Check your Makefile.defs file. There are many different options. Look at this section: DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ -DDBG_QM_MALLOC \ -DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
You can comment out F_MALLOC g-)
a c wrote:
hello,
having some problems loading the mysql module. I am using the latest dev release. couldn't find much help in the archieves..
ser -cf ser.mysql.cfg 0(1439) ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: /usr/local/lib/ser/modules/mysql.so: undefined symbol: fm_malloc 0(1439) parse error (15,13-14): failed to load module ERROR: bad config file (1 errors)
----------------config------------------ debug=3 fork=yes log_stderror=no
listen=192.168.0.5 port=5060 children=4
dns=no rev_dns=no
fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
I don't see any errors but could the gcc version make a difference?
%gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
--- "Greger V. Teigre" greger@teigre.com wrote:
I would check one more time and make sure that compilation and linking give no errors/warnings... g-)
a c wrote:
hello Greger,
seems like it is already commented out..hmm
DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ #-DDBG_QM_MALLOC \ #-DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
--- "Greger V. Teigre" greger@teigre.com wrote:
Looks like you have compiled with a memory alloc function not available. Check your Makefile.defs file. There are many different options. Look at this section: DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -DCFG_DIR='"$(cfg-target)"'\ -DPKG_MALLOC \ -DSHM_MEM -DSHM_MMAP \ -DDNS_IP_HACK \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ -DDBG_QM_MALLOC \ -DF_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DCONTACT_BUG \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM \ #-DSTATS \ #-DNO_LOG
You can comment out F_MALLOC g-)
a c wrote:
hello,
having some problems loading the mysql module. I
am
using the latest dev release. couldn't find much
help
in the archieves..
ser -cf ser.mysql.cfg 0(1439) ERROR: load_module: could not open
module
</usr/local/lib/ser/modules/mysql.so>: /usr/local/lib/ser/modules/mysql.so: undefined
symbol:
fm_malloc 0(1439) parse error (15,13-14): failed to load
module
ERROR: bad config file (1 errors)
----------------config------------------ debug=3 fork=yes log_stderror=no
listen=192.168.0.5 port=5060 children=4
dns=no rev_dns=no
fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Hi Steve, You just have to register ;-) g-)
Steve Blair wrote:
Greger V. Teigre wrote:
A part of the ONsip.org Getting Started effort is to make configuration files that can be used as a reference (and thus should be validated for correctness through theory and scrutiny from community). CANCELs can be in dialog and outside dialog and must thus be handled in two ways. In dialog they should be handled through the loose route (and basically t_relay'ed), while outside dialog they should be handled as INVITEs (credits go to Jan for explaining this in detail). Ex. this configuration file will show you this: http://www.onsip.org/modules/mydownloads/viewcat.php?cid=7
While this link is not accessible I appreciate the explanation.
Thanks.
g-)
a c wrote:
main route block..ac
# main routing logic route{
if (method == "CANCEL"){ t_relay(); }
...
--- Steve Blair blairs@isc.upenn.edu wrote:
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
I believe the 487 does not get matched because the UA which does the CANCEL never gets a 200 OK back since the CANCEL was not send out to the terminating UA by SER. For CANCEL, are we supposed to have special config? I don't have any specifically handles CANCEL {other than 487}.
ac
--- Steve Blair blairs@isc.upenn.edu wrote:
> I am having a similar problem. I am not yet > convinced that it is SER > as much as my configuration but if SER does have > difficulty processing > CANCEL messages it would be helpful to understand > under what > circumstances. > > By the way I have been using t_check_status in > > a
> similar way since > v 0.8 code. When I upgraded to 0.9.0, .0 and now > > .2
> the t_check_status > fails to be matched. > > -Steve > > Thanks,Steve > > a c wrote: > > > >> any ideas anyone? seems like SER does not respond >> >> > to > > >> CANCEL requests and eventually takes the failure >> route. >> >> I have the following in my failure route, but it >> >> > never > > >> gets hit, since SER does not send the 200 OK back >> >> > or > > >> pass the CANCEL message forward. log file >> >> attached.
>> failure_route[1] >> { >> if(t_check_status("487")) { >> # don't continue on cancellation >> xlog("L_WARN", "OH OH OH\n"); >> break; >> } >> >> ac >> >> >> --- a c lra101@yahoo.com wrote: >> >> >> >> >> >>> Seems like SER does not respond back to CANCEL >>> Requests. Is this a issue / some config problem >>> >>> on
>>> my >>> side? ngrep traces attached >>> >>> interface: eth0 (192.168.0.0/255.255.255.0) >>> filter: ip and ( port 5060 ) >>> # >>> U 192.168.0.2:5062 -> 192.168.0.5:5060 >>> INVITE sip:9999999999@voip.com SIP/2.0..Via: >>> SIP/2.0/UDP 192.168.0.2:5062;r >>> >>> >>> >>> >>> >>>
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
>> >> >> >> >>> 102 sip:102@voi >> p.com:5062>;tag=3282942385..To: >>> sip:9999999999@voip.com..Contact: sip:10 >> 2@192.168.0.2:5062>..Call-ID: >>> 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. >>> 0.2..CSeq: 940 INVITE..Max-Forwards: >>> 70..Content-Type: application/sdp..Use >>> r-Agent: X-Lite release 1103m..Content-Length: >>> 258....v=0..o=102 7659613 76 >>> 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 >>> 192.168.0.2..t=0 0..m=audio 80 >>> 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 >>> pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma >>> p:3 gsm/8000..a=rtpmap:98 >>> >>> iLBC/8000..a=rtpmap:96
>>> telephone-event/8000..a=fm >>> tp:96 0-15.. >>> >>>
> > > >>> >>> # >>> U 192.168.0.5:5060 -> 192.168.0.2:5062 >>> SIP/2.0 100 trying -- your call is important >>> >>> to
>>> us..Via: SIP/2.0/UDP 192.16 >>> >>> >>> >>> >>> >>>
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
>> >> >> >> >>> 102 >>> >>> sip:102@voip.com:5062;tag=3282942385..To:
>>> sip:9999999999@voip.com. >>> .Call-ID: >>> >>>
=== message truncated ===
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
yeah. i know. ;-)
Greger V. Teigre wrote:
Hi Steve, You just have to register ;-) g-)
Steve Blair wrote:
Greger V. Teigre wrote:
A part of the ONsip.org Getting Started effort is to make configuration files that can be used as a reference (and thus should be validated for correctness through theory and scrutiny from community). CANCELs can be in dialog and outside dialog and must thus be handled in two ways. In dialog they should be handled through the loose route (and basically t_relay'ed), while outside dialog they should be handled as INVITEs (credits go to Jan for explaining this in detail). Ex. this configuration file will show you this: http://www.onsip.org/modules/mydownloads/viewcat.php?cid=7
While this link is not accessible I appreciate the explanation.
Thanks.
g-)
a c wrote:
main route block..ac
# main routing logic route{
if (method == "CANCEL"){ t_relay(); }
...
--- Steve Blair blairs@isc.upenn.edu wrote:
humm. Where did you put it?
a c wrote:
thanks guys..t_relay was the problem. I did not have this in the config. issue is resolved.
ac --- a c lra101@yahoo.com wrote:
> I believe the 487 does not get matched because the > UA > which does the CANCEL never gets a 200 OK back since > the CANCEL was not send out to the terminating UA by > SER. For CANCEL, are we supposed to have special > config? I don't have any specifically handles CANCEL > {other than 487}. > > ac > > > --- Steve Blair blairs@isc.upenn.edu wrote: > > > >> I am having a similar problem. I am not yet >> convinced that it is SER >> as much as my configuration but if SER does have >> difficulty processing >> CANCEL messages it would be helpful to understand >> under what >> circumstances. >> >> By the way I have been using t_check_status in >> >> > a > > >> similar way since >> v 0.8 code. When I upgraded to 0.9.0, .0 and now >> >> > .2 > > >> the t_check_status >> fails to be matched. >> >> -Steve >> >> Thanks,Steve >> >> a c wrote: >> >> >> >>> any ideas anyone? seems like SER does not respond >>> >>> >> to >> >> >>> CANCEL requests and eventually takes the failure >>> route. >>> >>> I have the following in my failure route, but it >>> >>> >> never >> >> >>> gets hit, since SER does not send the 200 OK back >>> >>> >> or >> >> >>> pass the CANCEL message forward. log file >>> >>> > attached. > > >>> failure_route[1] >>> { >>> if(t_check_status("487")) { >>> # don't continue on cancellation >>> xlog("L_WARN", "OH OH OH\n"); >>> break; >>> } >>> >>> ac >>> >>> >>> --- a c lra101@yahoo.com wrote: >>> >>> >>> >>> >>> >>>> Seems like SER does not respond back to CANCEL >>>> Requests. Is this a issue / some config problem >>>> >>>> > on > > >>>> my >>>> side? ngrep traces attached >>>> >>>> interface: eth0 (192.168.0.0/255.255.255.0) >>>> filter: ip and ( port 5060 ) >>>> # >>>> U 192.168.0.2:5062 -> 192.168.0.5:5060 >>>> INVITE sip:9999999999@voip.com SIP/2.0..Via: >>>> SIP/2.0/UDP 192.168.0.2:5062;r >>>> >>>> >>>> >>>> >>>> >>>>
port;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> > >>> >>> >>> >>> >>>> 102 sip:102@voi >>> p.com:5062>;tag=3282942385..To: >>>> sip:9999999999@voip.com..Contact: sip:10 >>> 2@192.168.0.2:5062>..Call-ID: >>>> 29469D19-CDF1-49ED-8245-A67E1B1DBB88@192.168. >>>> 0.2..CSeq: 940 INVITE..Max-Forwards: >>>> 70..Content-Type: application/sdp..Use >>>> r-Agent: X-Lite release 1103m..Content-Length: >>>> 258....v=0..o=102 7659613 76 >>>> 59633 IN IP4 192.168.0.2..s=X-Lite..c=IN IP4 >>>> 192.168.0.2..t=0 0..m=audio 80 >>>> 00 RTP/AVP 0 8 3 98 96..a=rtpmap:0 >>>> pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpma >>>> p:3 gsm/8000..a=rtpmap:98 >>>> >>>> > iLBC/8000..a=rtpmap:96 > > >>>> telephone-event/8000..a=fm >>>> tp:96 0-15.. >>>> >>>> > > > >> >> >> >>>> >>>> # >>>> U 192.168.0.5:5060 -> 192.168.0.2:5062 >>>> SIP/2.0 100 trying -- your call is important >>>> >>>> > to > > >>>> us..Via: SIP/2.0/UDP 192.16 >>>> >>>> >>>> >>>> >>>> >>>>
8.0.2:5062;rport=5062;branch=z9hG4bKE29503D9D8CF4A479B6D9DDB17C5CFC1..From:
> > >>> >>> >>> >>> >>>> 102 >>>> >>>> > sip:102@voip.com:5062;tag=3282942385..To: > > >>>> sip:9999999999@voip.com. >>>> .Call-ID: >>>> >>>>
=== message truncated ===
Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers