_____
From: administrator [mailto:administrator@hellasfon.com] Sent: Wednesday, October 26, 2005 11:49 AM To: 'b2bua@vovida.org' Subject: EmbeddedObj.o Make error
Hello everybody,
I am trying to install b2bus from cvs and I get the following error:
make[1]: Leaving directory `/root/vocal/sip/sipstack'
make[1]: Entering directory `/root/vocal/sip/sipstack'
g++ -Wall -fPIC -Wno-deprecated -D_REENTRANT -DUSE_PTHREADS -g -I../../build -I../../build/../sdp/sdp2 -I../../build/../util -I../../build/../util/threads -I../../build/../util/logging -I../../build/../util/crypto -I../../build/../util/statistics -I../../build/../util/snmp -I../../build/../util/signals -I../../build/../util/behavior -I../../build/../util/io -I../../build/../util/services -I../../build/../util/transport -I../../build/../util/config -I../../build/../util/dnssrv -I../../build/../util/deprecated -I../../build/../util/adt -I../../build/../contrib/libxml2.Linux.i686 -I../../build/../contrib/libxml2.Linux.i686/include/libxml -I../../build/../contrib/libxml2.Linux.i686/include -DVOCAL_USE_DEPRECATED -DVOCAL_USING_PENTIUM -DOLD_PROV -c -o obj.debug.Linux.i686/EmbeddedObj.o EmbeddedObj.cxx
BaseUrl.hxx:146: error: specialization of βtemplate<class _Key> struct __gnu_cxx::hashβ in different namespace
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/hash_ fun.h:71: error: from definition of βtemplate<class _Key> struct __gnu_cxx::hashβ
EmbeddedObj.cxx: In member function βData Vocal::EmbeddedObj::doReverseEscape(const std::string&)β:
EmbeddedObj.cxx:213: warning: comparison between signed and unsigned integer expressions
make[1]: *** [obj.debug.Linux.i686/EmbeddedObj.o] Error 1
make[1]: Leaving directory `/root/vocal/sip/sipstack'
make: *** [sip] Error 2
I user SER(0.9.4) and freeRadius (latest) on Fedora Core 4.
Please Help ASAP.
Thank you in advance
Yiannis Marios
Hi All,
Our SER server is behind NAT, so we are having all sorts of NAT problems. I have tried to read all the information I was able to find on documents, maillist archives, and onsip and by googling. And I believe that I were able to solve SIP signalling problems by record routing, NAThelper and rtpproxy, and some tricks (double record routing) for HT486. So SIP signalling seems fine now. But when UAs are connected to sems, they send RTP messages to the local IP of SER. I also tried to use another ser instance dedicated to sems, but still the same. So I thought it's time to ask a couple of questions to the list.
To solve SIP problems, I tried to use advertised_address, but I could not see any effect of it, SER still advertises its local IP, afaics. I also tried mhomed. Apparently, I don't know how to use this parameter, I thougth it would function similar to externip/localnet parameters on Asterisk. So I tried solutions mentioned above, with success, as far as I can see. But ser.cfg becomes quite complicated. I wish I could use advertised_address properly.
To solve RTP problems, I tried to use mangler. But I need to manipulate messages sent from SER to the UA, for example 200 OK messages with SDP info. But, again I guess I don't know where to use sdp_mangle_ip function. I tried to use it in onreply_route without success. Where should I place it in ser.cfg? I guess I am missing something obvious. Would advertised_address solve this also, if I could have it working for me?
To summarize, I don't care too much about connections from local network (btw, I've set SER as DMZ), it's OK if SER forgets its local IP and always advertises its public IP. I want SER to put its public IP everywhere in every message (SIP/SDP) it sends out. Is there anyway to achive this?
I've done all these on both SER 0.9.4 and 0.10.99 (CVS HEAD a week from now), the server is a CentOS 4.1 x86_64.
I would appreciate any help. Sincerely, Soner Tari
Our SER server is behind NAT, so we are having all sorts of NAT problems. I have tried to read all the information I was able to find on documents, maillist archives, and onsip and by googling. And I believe that I were able to solve SIP signalling problems by record routing, NAThelper and rtpproxy, and some tricks (double record routing) for HT486. So SIP signalling seems fine now.
A few months back I posted a short how-to on that and people reported back that it worked, AFAIK. I don't really see why you need fouble record routing for HT486 unless you have an ALG in your NAT.
But when UAs are connected to sems, they send RTP messages to the local IP of SER. I also tried to use another ser instance dedicated to sems, but still the same. So I thought it's time to ask a couple of questions to the list.
To solve SIP problems, I tried to use advertised_address, but I could not see any effect of it, SER still advertises its local IP, afaics. I also tried mhomed. Apparently, I don't know how to use this parameter, I thougth it would function similar to externip/localnet parameters on Asterisk. So I tried solutions mentioned above, with success, as far as I can see. But ser.cfg becomes quite complicated. I wish I could use advertised_address properly.
adverstised_address should be used, it changes the IP address used in the Via header. mhomed is to be used if your box has two interfaces where one is public-facing and one is private and routing is done across.
To solve RTP problems, I tried to use mangler. But I need to manipulate messages sent from SER to the UA, for example 200 OK messages with SDP info. But, again I guess I don't know where to use sdp_mangle_ip function. I tried to use it in onreply_route without success. Where should I place it in ser.cfg? I guess I am missing something obvious. Would advertised_address solve this also, if I could have it working for me?
I'm not sure why sems send to SER's IP address. Unless you call force_rtp_proxy or use_media_proxy, the SDP address should not be changed.
To summarize, I don't care too much about connections from local network (btw, I've set SER as DMZ), it's OK if SER forgets its local IP and always advertises its public IP. I want SER to put its public IP everywhere in every message (SIP/SDP) it sends out. Is there anyway to achive this?
advertised_address=public_ip You also need to make sure that you have an alias statement for both the local IP and the public. If you want to use rtpproxy on all calls to sems, you can just make sure that you call force_rtp_proxy() on all INVITEs and OK (onreply) to/from sems. g-)
I've done all these on both SER 0.9.4 and 0.10.99 (CVS HEAD a week from now), the server is a CentOS 4.1 x86_64.
I would appreciate any help. Sincerely, Soner Tari
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thank you Greger for the reply. I took the original ser.cfg after first install and did what you suggest. However, with advertised_address I still have problems. SER keeps using SER's local IP in Contact and SDP o and c fields in the first OK after INVITE. So HT486 insists in using that local IP in ACK and BYEs (SJphone has no problems with the same OK message from SER, so I am trying to find a workaround for HT486).
Following is from the syslog debug from HT486, please pay attention to 200 OK from SER, it has SER's local IP (192.168.0.11) in 3 places, and then see the ACK from HT486, it is sent to that address instead of SER's public IP:
INVITE sip:8883630570@<SER.public.IP> SIP/2.0 Via: SIP/2.0/UDP <HT486.public.IP>;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>> Contact: <sip:8883630571@<HT486.public.IP>> Supported: replaces, timer Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE User-Agent: Grandstream HT487 1.0.7.11 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE Content-Type: application/sdp Content-Length: 340 v=0 o=8883630571 8000 8000 IN IP4 <HT486.public.IP> s=SIP Call c=IN IP4 <HT486.public.IP> t=0 0 m=audio 5004 RTP/AVP 18 4 97 8 0 101 a=sendrecv a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11
SIP/2.0 100 Trying -- just wait a minute ! Via: SIP/2.0/UDP 10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>> Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE Server: Sip EXpress router (0.9.4 (x86_64/linux)) Content-Length: 0 Warning: 392 192.168.0.11:5060 "Noisy feedback tells: pid=18295 req_src_ip=<HT486.public.IP> req_src_port=5060 in_uri=sip:8883630570@<SER.public.IP> out_uri=sip:8883630570@<SER.public.IP> via_cnt==1"
SIP/2.0 180 ringing Via: SIP/2.0/UDP 10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE Contact: sip:8883630570@192.168.0.11 Server: Sip EXpress router (0.9.4 (x86_64/linux)) Content-Length: 0 Warning: 392 192.168.0.11:5060 "Noisy feedback tells: pid=18292 req_src_ip=<HT486.public.IP> req_src_port=5060 in_uri=sip:8883630570@<SER.public.IP> out_uri=sip:8883630570@<SER.public.IP> via_cnt==0"
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE Contact: sip:8883630570@192.168.0.11 Content-Type: application/sdp Server: Sip EXpress router (0.9.4 (x86_64/linux)) Content-Length: 149 Warning: 392 192.168.0.11:5060 "Noisy feedback tells: pid=18292 req_src_ip=<HT486.public.IP> req_src_port=5060 in_uri=sip:8883630570@<SER.public.IP> out_uri=sip:8883630570@<SER.public.IP> via_cnt==0" v=0 o=username 0 0 IN IP4 192.168.0.11 s=session c=IN IP4 192.168.0.11 t=0 0 m=audio 1592 RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30
ACK sip:8883630570@192.168.0.11 SIP/2.0 Via: SIP/2.0/UDP <HT486.public.IP>;branch=z9hG4bKee2f9acde120c42b From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Contact: <sip:8883630571@<HT486.public.IP>> Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 ACK User-Agent: Grandstream HT487 1.0.7.11 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE Content-Length: 0
That's why I'm trying to use sdp mangler.
Btw, I need double record route as a workaround for another HT486 problem. I think it seems like there is a bug in HT486 record route processing (firmware 1.0.7.11, but also 1.0.6.7), it works like FIFO, when in fact it should work like LIFO, i.e. it uses the oldest Record-Route to reply a message. Using double record route, I am able to place the public IP of SER as the oldest Record-Route in 200 OK messages to fake HT486. I can quite easily replicate this issue and fake HT486 to use whatever IP I want by placing it as the last Record-Route. Stupid, I know.
Any comments? Thanks, Soner
----- Original Message ----- From: "Greger V. Teigre" greger@teigre.com To: "Soner Tari" list@kulustur.org; serusers@lists.iptel.org Sent: Monday, October 31, 2005 8:40 AM Subject: Re: [Serusers] SER/SEMS behind NAT, advertised_address, sdp_mangle_ip
Our SER server is behind NAT, so we are having all sorts of NAT problems. I have tried to read all the information I was able to find on documents, maillist archives, and onsip and by googling. And I believe that I were able to solve SIP signalling problems by record routing, NAThelper and rtpproxy, and some tricks (double record routing) for HT486. So SIP signalling seems fine now.
A few months back I posted a short how-to on that and people reported back that it worked, AFAIK. I don't really see why you need fouble record routing for HT486 unless you have an ALG in your NAT.
But when UAs are connected to sems, they send RTP messages to the local IP of SER. I also tried to use another ser instance dedicated to sems, but still the same. So I thought it's time to ask a couple of questions to the list.
To solve SIP problems, I tried to use advertised_address, but I could not see any effect of it, SER still advertises its local IP, afaics. I also tried mhomed. Apparently, I don't know how to use this parameter, I thougth it would function similar to externip/localnet parameters on Asterisk. So I tried solutions mentioned above, with success, as far as I can see. But ser.cfg becomes quite complicated. I wish I could use advertised_address properly.
adverstised_address should be used, it changes the IP address used in the Via header. mhomed is to be used if your box has two interfaces where one is public-facing and one is private and routing is done across.
To solve RTP problems, I tried to use mangler. But I need to manipulate messages sent from SER to the UA, for example 200 OK messages with SDP info. But, again I guess I don't know where to use sdp_mangle_ip function. I tried to use it in onreply_route without success. Where should I place it in ser.cfg? I guess I am missing something obvious. Would advertised_address solve this also, if I could have it working for me?
I'm not sure why sems send to SER's IP address. Unless you call force_rtp_proxy or use_media_proxy, the SDP address should not be changed.
To summarize, I don't care too much about connections from local network (btw, I've set SER as DMZ), it's OK if SER forgets its local IP and always advertises its public IP. I want SER to put its public IP everywhere in every message (SIP/SDP) it sends out. Is there anyway to achive this?
advertised_address=public_ip You also need to make sure that you have an alias statement for both the local IP and the public. If you want to use rtpproxy on all calls to sems, you can just make sure that you call force_rtp_proxy() on all INVITEs and OK (onreply) to/from sems. g-)
I've done all these on both SER 0.9.4 and 0.10.99 (CVS HEAD a week from now), the server is a CentOS 4.1 x86_64.
I would appreciate any help. Sincerely, Soner Tari
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Sorry, didn't realize that you probably had rtpproxy behind NAT as well. Have a look at this thread for mediaproxy: http://www.onsip.org/modules/newbb/viewtopic.php?topic_id=47&forum=2 I also posted a patch for rtpproxy. http://lists.iptel.org/pipermail/serusers/2005-January/014688.html
AFAIK, none of them have been included in recent versions of rtpproxy/mediaproxy and both patches are for older versions. As for HT486, you are describing a very important breach of the RFC... Either that, or it does not recognize your ser as a loose router and believes it is a strict router (check for lr or lr=on in the Record-Route). g-)
----- Original Message ----- From: "Soner Tari" list@kulustur.org To: serusers@lists.iptel.org Sent: Wednesday, November 02, 2005 10:25 PM Subject: Re: [Serusers] SER/SEMS behind NAT, advertised_address, sdp_mangle_ip
Thank you Greger for the reply. I took the original ser.cfg after first install and did what you suggest. However, with advertised_address I still have problems. SER keeps using SER's local IP in Contact and SDP o and c fields in the first OK after INVITE. So HT486 insists in using that local IP in ACK and BYEs (SJphone has no problems with the same OK message from SER, so I am trying to find a workaround for HT486).
Following is from the syslog debug from HT486, please pay attention to 200 OK from SER, it has SER's local IP (192.168.0.11) in 3 places, and then see the ACK from HT486, it is sent to that address instead of SER's public IP:
INVITE sip:8883630570@<SER.public.IP> SIP/2.0 Via: SIP/2.0/UDP <HT486.public.IP>;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>> Contact: <sip:8883630571@<HT486.public.IP>> Supported: replaces, timer Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE User-Agent: Grandstream HT487 1.0.7.11 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE Content-Type: application/sdp Content-Length: 340 v=0 o=8883630571 8000 8000 IN IP4 <HT486.public.IP> s=SIP Call c=IN IP4 <HT486.public.IP> t=0 0 m=audio 5004 RTP/AVP 18 4 97 8 0 101 a=sendrecv a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11
SIP/2.0 100 Trying -- just wait a minute ! Via: SIP/2.0/UDP 10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>> Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE Server: Sip EXpress router (0.9.4 (x86_64/linux)) Content-Length: 0 Warning: 392 192.168.0.11:5060 "Noisy feedback tells: pid=18295 req_src_ip=<HT486.public.IP> req_src_port=5060 in_uri=sip:8883630570@<SER.public.IP> out_uri=sip:8883630570@<SER.public.IP> via_cnt==1"
SIP/2.0 180 ringing Via: SIP/2.0/UDP 10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE Contact: sip:8883630570@192.168.0.11 Server: Sip EXpress router (0.9.4 (x86_64/linux)) Content-Length: 0 Warning: 392 192.168.0.11:5060 "Noisy feedback tells: pid=18292 req_src_ip=<HT486.public.IP> req_src_port=5060 in_uri=sip:8883630570@<SER.public.IP> out_uri=sip:8883630570@<SER.public.IP> via_cnt==0"
SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 INVITE Contact: sip:8883630570@192.168.0.11 Content-Type: application/sdp Server: Sip EXpress router (0.9.4 (x86_64/linux)) Content-Length: 149 Warning: 392 192.168.0.11:5060 "Noisy feedback tells: pid=18292 req_src_ip=<HT486.public.IP> req_src_port=5060 in_uri=sip:8883630570@<SER.public.IP> out_uri=sip:8883630570@<SER.public.IP> via_cnt==0" v=0 o=username 0 0 IN IP4 192.168.0.11 s=session c=IN IP4 192.168.0.11 t=0 0 m=audio 1592 RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30
ACK sip:8883630570@192.168.0.11 SIP/2.0 Via: SIP/2.0/UDP <HT486.public.IP>;branch=z9hG4bKee2f9acde120c42b From: "Soner Tari" <sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To: <sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Contact: <sip:8883630571@<HT486.public.IP>> Call-ID: 96900515ab0729c3@10.0.0.6 CSeq: 54703 ACK User-Agent: Grandstream HT487 1.0.7.11 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE Content-Length: 0
That's why I'm trying to use sdp mangler.
Btw, I need double record route as a workaround for another HT486 problem. I think it seems like there is a bug in HT486 record route processing (firmware 1.0.7.11, but also 1.0.6.7), it works like FIFO, when in fact it should work like LIFO, i.e. it uses the oldest Record-Route to reply a message. Using double record route, I am able to place the public IP of SER as the oldest Record-Route in 200 OK messages to fake HT486. I can quite easily replicate this issue and fake HT486 to use whatever IP I want by placing it as the last Record-Route. Stupid, I know.
Any comments? Thanks, Soner
----- Original Message ----- From: "Greger V. Teigre" greger@teigre.com To: "Soner Tari" list@kulustur.org; serusers@lists.iptel.org Sent: Monday, October 31, 2005 8:40 AM Subject: Re: [Serusers] SER/SEMS behind NAT, advertised_address, sdp_mangle_ip
Our SER server is behind NAT, so we are having all sorts of NAT problems. I have tried to read all the information I was able to find on documents, maillist archives, and onsip and by googling. And I believe that I were able to solve SIP signalling problems by record routing, NAThelper and rtpproxy, and some tricks (double record routing) for HT486. So SIP signalling seems fine now.
A few months back I posted a short how-to on that and people reported back that it worked, AFAIK. I don't really see why you need fouble record routing for HT486 unless you have an ALG in your NAT.
But when UAs are connected to sems, they send RTP messages to the local IP of SER. I also tried to use another ser instance dedicated to sems, but still the same. So I thought it's time to ask a couple of questions to the list.
To solve SIP problems, I tried to use advertised_address, but I could not see any effect of it, SER still advertises its local IP, afaics. I also tried mhomed. Apparently, I don't know how to use this parameter, I thougth it would function similar to externip/localnet parameters on Asterisk. So I tried solutions mentioned above, with success, as far as I can see. But ser.cfg becomes quite complicated. I wish I could use advertised_address properly.
adverstised_address should be used, it changes the IP address used in the Via header. mhomed is to be used if your box has two interfaces where one is public-facing and one is private and routing is done across.
To solve RTP problems, I tried to use mangler. But I need to manipulate messages sent from SER to the UA, for example 200 OK messages with SDP info. But, again I guess I don't know where to use sdp_mangle_ip function. I tried to use it in onreply_route without success. Where should I place it in ser.cfg? I guess I am missing something obvious. Would advertised_address solve this also, if I could have it working for me?
I'm not sure why sems send to SER's IP address. Unless you call force_rtp_proxy or use_media_proxy, the SDP address should not be changed.
To summarize, I don't care too much about connections from local network (btw, I've set SER as DMZ), it's OK if SER forgets its local IP and always advertises its public IP. I want SER to put its public IP everywhere in every message (SIP/SDP) it sends out. Is there anyway to achive this?
advertised_address=public_ip You also need to make sure that you have an alias statement for both the local IP and the public. If you want to use rtpproxy on all calls to sems, you can just make sure that you call force_rtp_proxy() on all INVITEs and OK (onreply) to/from sems. g-)
I've done all these on both SER 0.9.4 and 0.10.99 (CVS HEAD a week from now), the server is a CentOS 4.1 x86_64.
I would appreciate any help. Sincerely, Soner Tari
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
administrator -
Greger V. Teigre -
Soner Tari