You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
|
Sep
(6) |
Oct
|
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Seongkyoun Y. <seo...@gm...> - 2007-11-09 06:24:23
|
Hi all I have some problem in SARP-0.3pre2 . I'd like to use a SARP behind firewall. Registration is succeeded in UA(Linphone Windows). but I can't use a UA through SARP. please let me know what was wrong. see the below SARP's logs 23:06:51 * Unknown Call-ID: Use of uninitialized value in substitution (s///) at /usr/local/bin/sarp.pl line 629. Use of uninitialized value in pattern match (m//) at /usr/local/bin/sarp.pl line 630. Use of uninitialized value in pattern match (m//) at /usr/local/bin/sarp.pl line 631. Use of uninitialized value in hash element at /usr/local/bin/sarp.pl line 634. Use of uninitialized value in concatenation (.) or string at /usr/local/bin/sarp.pl line 731. 23:07:01 * Unknown Call-ID: 23:07:08 - Removing registration: aaa11@192.*.*.24 23:07:18 - Removing registration: bbb11@192.*.*.27 thanks in advanced Regards Seongkyoun Yoo -- Seongkyoun Yoo |
From: <ben...@id...> - 2004-05-22 12:30:08
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: <Uri...@nc...> - 2003-11-18 14:42:02
|
Andrew: I have been using Asterisk for a long time but have grown disappointed = with Asteriks handling of SIP registration and when both Asterisk and SIP-ph= ones are behind a NAT. I am in the process of testing SARP to replace Aster= isk in handling all of my SIP phones that are mostly in Central America, th= e USA and Canada. Obviously I will still need Asterisk to continue interconnecting to the PSTN as a Gateway so my SIP users can be given a= regular public telephone number. do you have any advise in dealing with the NAT issue? do you have any adivse for connecting SARP and Asterisk? Regards, Uri...@nc... NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Gr=FC=DFen / Med v=E4nlig h=E4lsning = |
From: Andrew R. <an...@ra...> - 2003-11-18 04:20:26
|
Hi, Sorry for the delay in my reply. I would say that the status of SaRP is that it works for the most part as a SIP and RTP proxy. But, really we got it to the point that it does the job and since then pretty much stopped working on it. Unfortunately, myself and the other developer basically both got unbelievably frustrated with the mess that SIP is. So in that sense it is alpha or early beta level. That being said, I have it running constantly here and it does it's job and just works. If there was a little bit of interest in it, it really wouldn't take much work to get it from where it is to being totally solid and reliable. Are you at all interested in assisting or know anyone who is? Regards, Andrew Radke Dean Nedelman wrote: > I am "involved" with a Linux distribution known as Devil-Linux (designed > primarily as a small CD based security enhanced router/firewall). I have > been arguing for the inclusion of something to resolve the SIP/NAT issue. > > I had originally requested the inclusion of Siproxd, but withdrew that > request because Siproxd doesn't support IPTables and replaced it with a > request for SaRP. The maintainer of Devil-Linux is reluctant to include > SaRP because the Sourceforge summary page still shows the project in Alpha > status. > > So, my question [finally] is this: Is this project still considered at > Alpha level? > > Thanks. > > Dean Nedelman > TimeLord Consulting > > [Also, I am not registered for the mailing list - so please CC me with your > response.] |
From: Dean N. <din...@ti...> - 2003-11-16 18:42:21
|
I am "involved" with a Linux distribution known as Devil-Linux (designed primarily as a small CD based security enhanced router/firewall). I have been arguing for the inclusion of something to resolve the SIP/NAT issue. I had originally requested the inclusion of Siproxd, but withdrew that request because Siproxd doesn't support IPTables and replaced it with a request for SaRP. The maintainer of Devil-Linux is reluctant to include SaRP because the Sourceforge summary page still shows the project in Alpha status. So, my question [finally] is this: Is this project still considered at Alpha level? Thanks. Dean Nedelman TimeLord Consulting [Also, I am not registered for the mailing list - so please CC me with your response.] |
From: Andrew R. <an...@ra...> - 2003-09-30 04:53:23
|
Hugo Villeneuve wrote: > Hi Andrew, > > This is the most easy SIP proxy to install I have seen, congratulations! I have tried to install partysip or siproxd, but I was never able to make them work. Now my problem: I have installed sarp on my server, and from a linux box on my LAN I can call someone via the internet and it works. When that same person try to call me, the sarp proxy says: > > "INVITE from non-local host for a non-registered user..." > > How can I register a user with sarp? Is it a configuration option in the config file? > > Thank-you, Hugo. Thanks for you comments and my apologies for the lateness of my reply. That message means that SaRP doesn't have the address that the person is calling listed as a registered user. When you setup your client it will register a full address similar to an email address and this is what SaRP uses to know where to forward incoming calls to. Your logs should look something like this: 14:43:28 < REGISTER sip:******.dyndns.org SIP/2.0 from 192.168.x.y:5060 14:43:28 > '200 Ok' to 192.168.x.y:5060 14:43:28 - Registered users (2): 14:43:28 `-- andrew@*****.dyndns.org : 192.168.x.y:5060 : 14:51:27 This shows that user 'andrew@*****.dyndns.org' registered on '192.168.x.y:5060' and the registration will expire at '14:51:27'. The person calling you will have to be calling 'andrew@*****.dyndns.org' for SaRP to know where to forward the call to. And '*****.dyndns.org' will have to resolve in some way to your server or to a router forwarding port UDP/5060 to the SaRP server. I hope this helps. Regards, Andrew |
From: Andrew R. <an...@ra...> - 2003-09-30 04:41:17
|
Uri...@nc... wrote: > Hi there! > I am wondering if I can run my Soft-SIP phone (on Linux RedHat 9) along > side with the SaRP daemon in the same box? > I use a LynkSys NAT router on one side and the other person across the > Internet a D-Link NAT on the other side with a real hardware SIP-PHONE. > > Configuration: > SIP(GrandStream Budget hardware phone) ------ D-Link NAT ------- INTERNET > ------ LinkSys NAT ------ SIP (soft-phone on Linux) with SaRP > > I don't have control over the SIP(GrandStream) and the person using this > phone does not have more than a WIN machine for home use and the D-Link > router. would this work? > > Regards, > > Uri...@nc... Having a UA and SaRP on the same machine shouldn't pose any problems so long as you make sure to set the UA to use a port other than UDP/5060 and have the LinkSys forward UDP/5060 to the machine running SaRP. Which UA are you going to use? I haven't had time to get around to rewriting the REGISTER code in SaRP and the Linux UAs I've tried have been very strict and generally don't like what I give back. As for the other end... Good lick. Maybe the D-Link will support NATing SIP in which case they'll probably be able to call out, but whether they will be able to receive calls, even after forwarding port UDP/5060 to their machine from the D-Link is really up to what the D-Link does. SaRP should run perfectly well with ActivePerl on Windows though if you want to get them to install it. Regards, Andrew Radke |
From: <Uri...@nc...> - 2003-09-29 15:31:21
|
Hi there! I am wondering if I can run my Soft-SIP phone (on Linux RedHat 9) along= side with the SaRP daemon in the same box? I use a LynkSys NAT router on one side and the other person across the Internet a D-Link NAT on the other side with a real hardware SIP-PHONE.= Configuration: SIP(GrandStream Budget hardware phone) ------ D-Link NAT ------- INTERN= ET ------ LinkSys NAT ------ SIP (soft-phone on Linux) with SaRP I don't have control over the SIP(GrandStream) and the person using thi= s phone does not have more than a WIN machine for home use and the D-Link= router. would this work? Regards, Uri...@nc... NCCI Boca Raton, Florida 561.893.2415 greetings / avec mes meilleures salutations / Cordialmente mit freundlichen Gr=FC=DFen / Med v=E4nlig h=E4lsning = |
From: mattf <ma...@vi...> - 2003-09-03 14:00:03
|
Hello, I fixed it, very simple actually it's just a Redhat 9 problem I just executed the command "export LANG=C" from command line and everything is happy now. something to do with redhat making UTF-8 the default language on its new installs now. It seems to break many things. Here's a posting about it: http://cheerleader.yoz.com/archives/000806.html it didn't matter what codec I was using, I tried 711u, 711a and 729. But they all work now. Thanks for your help. MATT--- -----Original Message----- From: Andrew Radke [mailto:an...@ra...] Sent: Tuesday, September 02, 2003 8:48 PM To: sar...@li... Cc: ma...@vi... Subject: Re: [Sarp-users] Malformed UTF-8 character errors Hmm, That is a very interesting error. The obvious link between those 4 lines is that they are dealing with the RTP packet. At no point do we ever try to interpret the contents of that packet. The closest we ever get to that is to read the length of it but that would only account for lines 377 and 382. For some reason it looks like Perl is trying to treat this data as UTF-8 formatted text. I'm guessing this is because of some data at the beginning of the packet. What codec and client are you using? And does it go away if you try using a different codec? (I use Speex almost exclusively). Regards, Andrew On Tue, Sep 02, 2003 at 05:51:09PM -0400, mattf wrote: > Hello, > > After some trial and error with my firewalls I was able to get sarp running, > it now connects wonderfully. > > Redhat 9 > Linksys firewall/gateway (I couldn't get my very strict iptables firewall to > let and any audio through) > sarp 3 rc2 > > I am having a lot of errors show up with Malformed UTF-8 characters: > > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 377. > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 379. > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 382. > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 384. > > several hundred of these show up per minute. > > Should this worry me or should I just turn the error messages off and forget > about it? > > Thanks, > > MATT--- |
From: Andrew R. <an...@ra...> - 2003-09-03 00:47:59
|
Hmm, That is a very interesting error. The obvious link between those 4 lines is that they are dealing with the RTP packet. At no point do we ever try to interpret the contents of that packet. The closest we ever get to that is to read the length of it but that would only account for lines 377 and 382. For some reason it looks like Perl is trying to treat this data as UTF-8 formatted text. I'm guessing this is because of some data at the beginning of the packet. What codec and client are you using? And does it go away if you try using a different codec? (I use Speex almost exclusively). Regards, Andrew On Tue, Sep 02, 2003 at 05:51:09PM -0400, mattf wrote: > Hello, > > After some trial and error with my firewalls I was able to get sarp running, > it now connects wonderfully. > > Redhat 9 > Linksys firewall/gateway (I couldn't get my very strict iptables firewall to > let and any audio through) > sarp 3 rc2 > > I am having a lot of errors show up with Malformed UTF-8 characters: > > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 377. > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 379. > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 382. > Malformed UTF-8 character (unexpected end of string) at > /usr/local/sarp/sarp.pl line 384. > > several hundred of these show up per minute. > > Should this worry me or should I just turn the error messages off and forget > about it? > > Thanks, > > MATT--- |
From: mattf <ma...@vi...> - 2003-09-02 21:57:38
|
Hello, After some trial and error with my firewalls I was able to get sarp running, it now connects wonderfully. Redhat 9 Linksys firewall/gateway (I couldn't get my very strict iptables firewall to let and any audio through) sarp 3 rc2 I am having a lot of errors show up with Malformed UTF-8 characters: Malformed UTF-8 character (unexpected end of string) at /usr/local/sarp/sarp.pl line 377. Malformed UTF-8 character (unexpected end of string) at /usr/local/sarp/sarp.pl line 379. Malformed UTF-8 character (unexpected end of string) at /usr/local/sarp/sarp.pl line 382. Malformed UTF-8 character (unexpected end of string) at /usr/local/sarp/sarp.pl line 384. several hundred of these show up per minute. Should this worry me or should I just turn the error messages off and forget about it? Thanks, MATT--- |
From: Andrew R. <an...@ra...> - 2003-07-31 07:05:18
|
The good news is that the code for dealing with passing calls through is actually rather simple if you rely on the UAs doing their thing properly. Ending calls is harder but I'm getting there and most of my Perl code for all of this should be relatively easily ported to C++ One thing Dylan didn't mention is that he is coding under Windows. Most of the code should be directly portable (or some minor changes) but there will be a little bit of work to be done getting it into *nix land. Being able to compile it as a service under Windows or a daemon under *nix will be a wonderful thing though. :-) Regards Andrew Radke On Thu, Jul 31, 2003 at 04:14:31PM +1000, Dylan Walkden wrote: > The C++ source isn't really ready for post as yet. I've done all the > basic framework such as the code to receive packets, parse them, etc. If > real life hadn't interrupted me I'd probably be finishing up the code to > handle the Registrar side of things, I have most of it done I just need to > add code to drop duplicate packets from a transaction. Also the code that > generates the reply packet needs a bit of work, I missed a section in the > RFC when I was skimming over it. And I really need to edit out some of the > more "interesting" diagnostic messages I put in there while debugging late > at night. Useful comments would probably help to, at the moment they are > just in there to jog my memory and tend to be a tad cryptic. > But sure, once I get my act together the more help on this the merrier. > :) Do you have any particular specialties when it comes to coding Szabolcs? > > - Dylan. |
From: Dylan W. <dyl...@ho...> - 2003-07-31 06:22:54
|
The C++ source isn't really ready for post as yet. I've done all the basic framework such as the code to receive packets, parse them, etc. If real life hadn't interrupted me I'd probably be finishing up the code to handle the Registrar side of things, I have most of it done I just need to add code to drop duplicate packets from a transaction. Also the code that generates the reply packet needs a bit of work, I missed a section in the RFC when I was skimming over it. And I really need to edit out some of the more "interesting" diagnostic messages I put in there while debugging late at night. Useful comments would probably help to, at the moment they are just in there to jog my memory and tend to be a tad cryptic. But sure, once I get my act together the more help on this the merrier. :) Do you have any particular specialties when it comes to coding Szabolcs? - Dylan. ----- Original Message ----- From: <sar...@li...> To: <sar...@li...> Sent: Thursday, July 31, 2003 1:27 PM Subject: Sarp-users digest, Vol 1 #5 - 1 msg > Send Sarp-users mailing list submissions to > sar...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/sarp-users > or, via email, send a message with subject or body 'help' to > sar...@li... > > You can reach the person managing the list at > sar...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sarp-users digest..." > > > Today's Topics: > > 1. Re: SIP NAT traversal (contribution) (Andrew Radke) > > --__--__-- > > Message: 1 > Date: Wed, 30 Jul 2003 14:18:14 +1000 > From: Andrew Radke <an...@ra...> > To: Szabolcs Szasz <sz...@sz...> > Cc: sar...@li... > Subject: [Sarp-users] Re: SIP NAT traversal (contribution) > > Hi, > > Thanks for the offer. I'm not doing any of the work on the C++ version > except providing information on how things are working for me on the > Perl version. Unfortunately I'm not a programmer :-(. I will forward > your offer to Dylan who is doing this work though. (about time he let > the rest of us see some of his code anyway :-). > > So to your original questions: firewall changes will NOT be required for > outgoing calls so long as any outgoing traffic from the SaRP server is > allowed. Incoming calls will require the SIP port (5060 by default) to > be accessible on the SaRP server. If the SaRP server has a real world IP > then this just means allowing that traffic through or if it uses a > private IP then forwarding anything on port 5060 to it. As for the RTP > traffic this should be fine so long as any traffic from the server is > allowed out or otherwise follow the same procedure for the ports listed > in your config file as for port 5060. > > As for IPFreedom, I am not familiar with them so I can't comment. Could > you provide more information? > > And lastly, as far as communication is concerned the best place to get > in touch would probably be simply using the SaRP mailing lists. I'll > have to add links to them directly on the homepage, but for now use the > Sourceforge pages. (email me directly if you have problems) > > Regards, > > Andrew Radke > > > On Tue, Jul 29, 2003 at 02:06:58PM +0200, Szabolcs Szasz wrote: > > Oops, I forgot to tell, that there is some fair chance I could > > contribute to the C++ version sometime in the near future. > > > > BTW, do you happen to know of any commercial alternatives > > to IPFreedom? > > > > Cheers, > > Sz. > > > > ----- Original Message ----- > > From: "Szabolcs Szasz" <sz...@sz...> > > To: <an...@ra...> > > Sent: Tuesday, July 29, 2003 1:59 PM > > Subject: Fw: SIP NAT traversal > > > > > > > Just in case, I forward this to your other mail address > > > (found in the SARP copyright notice). > > > > > > Later, > > > Sz. > > > > > > ----- Original Message ----- > > > From: "Szabolcs Szasz" <sz...@sz...> > > > To: <ar...@us...> > > > Sent: Tuesday, July 29, 2003 1:56 PM > > > Subject: SIP NAT traversal > > > > > > > > > > Hi, > > > > > > > > Just found your project! Very cool that someone really > > > > started doing it. In fact, I also found myself in a situation > > > > just now, where I need some solution to this problem. > > > > > > > > As I understand, your stuff requires firewall reconfiguration > > > > (however minimal). Is that indeed the case? > > > > > > > > I'm investigating a solution that is more like the IPFreedom > > > > client-server model. How close/far is your architecture > > > > to/from theirs? > > > > > > > > (What would be the preferred way of keeping contact? > > > > Is this your mail address OK for this purpose?) > > > > > > > > Thanks, > > > > Szabolcs > > > > > > > > > > > > > --__--__-- > > _______________________________________________ > Sarp-users mailing list > Sar...@li... > https://lists.sourceforge.net/lists/listinfo/sarp-users > > > End of Sarp-users Digest > |
From: Andrew R. <an...@ra...> - 2003-07-30 04:43:46
|
Hi, Thanks for the offer. I'm not doing any of the work on the C++ version except providing information on how things are working for me on the Perl version. Unfortunately I'm not a programmer :-(. I will forward your offer to Dylan who is doing this work though. (about time he let the rest of us see some of his code anyway :-). So to your original questions: firewall changes will NOT be required for outgoing calls so long as any outgoing traffic from the SaRP server is allowed. Incoming calls will require the SIP port (5060 by default) to be accessible on the SaRP server. If the SaRP server has a real world IP then this just means allowing that traffic through or if it uses a private IP then forwarding anything on port 5060 to it. As for the RTP traffic this should be fine so long as any traffic from the server is allowed out or otherwise follow the same procedure for the ports listed in your config file as for port 5060. As for IPFreedom, I am not familiar with them so I can't comment. Could you provide more information? And lastly, as far as communication is concerned the best place to get in touch would probably be simply using the SaRP mailing lists. I'll have to add links to them directly on the homepage, but for now use the Sourceforge pages. (email me directly if you have problems) Regards, Andrew Radke On Tue, Jul 29, 2003 at 02:06:58PM +0200, Szabolcs Szasz wrote: > Oops, I forgot to tell, that there is some fair chance I could > contribute to the C++ version sometime in the near future. > > BTW, do you happen to know of any commercial alternatives > to IPFreedom? > > Cheers, > Sz. > > ----- Original Message ----- > From: "Szabolcs Szasz" <sz...@sz...> > To: <an...@ra...> > Sent: Tuesday, July 29, 2003 1:59 PM > Subject: Fw: SIP NAT traversal > > > > Just in case, I forward this to your other mail address > > (found in the SARP copyright notice). > > > > Later, > > Sz. > > > > ----- Original Message ----- > > From: "Szabolcs Szasz" <sz...@sz...> > > To: <ar...@us...> > > Sent: Tuesday, July 29, 2003 1:56 PM > > Subject: SIP NAT traversal > > > > > > > Hi, > > > > > > Just found your project! Very cool that someone really > > > started doing it. In fact, I also found myself in a situation > > > just now, where I need some solution to this problem. > > > > > > As I understand, your stuff requires firewall reconfiguration > > > (however minimal). Is that indeed the case? > > > > > > I'm investigating a solution that is more like the IPFreedom > > > client-server model. How close/far is your architecture > > > to/from theirs? > > > > > > (What would be the preferred way of keeping contact? > > > Is this your mail address OK for this purpose?) > > > > > > Thanks, > > > Szabolcs > > > > > > |
From: Andrew R. <an...@ra...> - 2003-07-22 03:21:35
|
Hello again. I've just put 0.3pre2 up. Anyone using 0.3pre1 will by now know that it's completely broken for making calls. Also the README and INSTALL files were out of date and misleading. So if you want to try it out then grab it from the usual place. If you want something that I know works then maybe stick to 0.2.1. Regards, Andrew Radke |
From: Andrew R. <an...@ra...> - 2003-07-21 05:46:58
|
Hi all, I've just uploaded 0.3pre1 to the website. There are a number of small (but nice) changes and one really BIG one. Thanks to Dylan for his idea on how to get that one working. Anyway, without further fanfare, the release notes and changelog. Regards, Andrew Radke ------------------------------ This is a fairly big release from the point of view of aiming for a truely usable piece of software. Firstly the three biggest things from a first glance: 1) sarp.pl will daemonise by default. 2) Messages now go to a log file rather than stderr. 3) The config file is now /etc/sarp/config Unfortunately all three of these things move us a little further away from Windows compatibility. We are really now at the point where there will need to be a test of which OS we are running on and changing some setting from there. BUT, the big change is: We now monitor SIP traffic involved in an active call and if we don't see anything from a UA for a period of time we will send an OPTIONS message as a kind of 'ping'. It will try a few times before giving up and hanging up the call. There are situations where this will not work perfectly (a UA dies and restarts between 'ping's) but it will get the majority of dead calls. This is really usefull when a UA is a softphone and the user doesn't have the physical act of hanging up method of causing the call to terminate. As far as I know no other SIP software has anything similar. ------------------------------ Changes to SaRP 0.3pre1 * SaRP now monitors SIP traffic from UAs involved in a call and if no traffic is seen then uses an OPTIONS packet as a sort of 'ping'. * default behaviour is now to daemonise. * default behaviour is now to log to $logfile (default is * /var/log/sarp.log) * Some code cleanup Changes to SaRP 0.2.1 * Fixed the port used for sending datat back to the requesting UA * Added bandwidth usage to report at end of RTP proxy. * Cleaned up the adding and deleting of alarms * Changed the printing of messages to support a 'verbosity' level Changes to SaRP 0.2 * Added a config file (only works on *nix like machines). * Should run on Windows just fine. * Added alarms so that events can now happen at set times. * LOTS of clean up of the code. Changes to SaRP 0.1 * Initial release |
From: Andrew R. <an...@ra...> - 2003-07-19 14:17:07
|
Hi, I won't get the chance to answer more for a day or so, so I'll give some quick answers now and more detailed answers later if needed. Adrien Pestel wrote: > Hi, > > > > I would like to test your solution to make VoIP calls behind NAT. Go for v0.2.1. I've started working on some cool new features in CVS for 0.3 and I really don't know how well it will tie together yet. If you wanna play with keepalive's for instance, you can go with CVS. I usually try to avoid uploading anything that doesn't work :-). Just be aware that it is still very much development. For instance all status messages are sent to the console until I get a good cross-platform loggin system in place. That will hopefully be in for 0.3 > I’ve got few questions. > > > > 1) What UA are compatible with your solution (Linux & Windows if possible) I'm aiming for 100% compatibility (if that's even possible :-( ). So far tested UAs are X-Lite and SJPhone. I don't have any hardware devices for the time being. Personally I prefer X-Lite especially since it uses the Speex codec which is _very_ impressive! Both of these are Windows programs since I haven't been real happy with any of the Linux clients. > 2) Is it compatible with a SIP Porxy and/or SIP registrar Dunno. Keep meaning to look into this. I really can't see why not. It does have a registrar built in and for what I want works perfectly. You'd be talking about FWD or iptel? > 3) Imagine Endpoint1 is behind a NAT and Endpoint2 is behind another > NAT. Is it possible to make a Call like Endpoint1 call Endpoint2 ? Certainly! In fact we use it that way for communication during development. Almost everyone I know is behind a NAT of some kind and it seems none of can afford all the Cisco gear a lot of SIP developers assume you should have :-). As to whether it will work if you have the following: UA1 <-> SaRP <-> NAT <-> NAT <-> UA2 That will depend a little on your NAT and a little on UA2. For instance there is no reason it won't work if UA2 is SJPhone and calls originate from it since it sends RTP data on the same port as it receives and therefore most NAT devices will pass the audio through in both directions (SaRP does the same thing). X-Lite sends RTP from a seperate socket and therefore different port to what it receives and therefore doesn't play nicely with any NAT. This is infact something I keep meaning to raise with them. > Thank you for your answers. No problem. I'd be very happy to hear your comments and experiences. If you have any problems let me know. > Cheers, > -- > > Adrien Pestel (EPITA/3IE) Regards, Andrew Radke |
From: Andrew R. <an...@ra...> - 2003-07-17 03:23:53
|
Hi all, I've released 0.2.1 as an immediate fix to the incorrectly used port problem. I've posted the changelog below. I recommend anyone using v0.2 upgrade to avoid possible problems with clients that can reside on ports other than 5060 (E.g. X-Lite). Regards, Andrew Radke ----------------------------------------------------------------- Changes to SaRP 0.2.1 * Fixed the port used for sending datat back to the requesting UA * Added bandwidth usage to report at end of RTP proxy. * Cleaned up the adding and deleting of alarms * Changed the printing of messages to support a 'verbosity' level Changes to SaRP 0.2 * Added a config file (only works on *nix like machines). * Should run on Windows just fine. * Added alarms so that events can now happen at set times. * LOTS of clean up of the code. Changes to SaRP 0.1 * Initial release |
From: Andrew R. <an...@ra...> - 2003-07-02 13:07:11
|
Instead of this make notes of some of the faults in SIP that cause you problems and start working towards SIP/2.1 or SIP/3.0. Just because you weren't one of the people involved in designing the existing protocol doesn't mean you can't work to change it. SIP 2.0 has some unbeleivably braindead concepts in it. It is so loose that you can find one peice of info in half a dozen places in a SIP packet. It has no tightly defined structure and has no concept of how to work in a real-world network. Security wasn't truly even an afterthought which in the modern Internet environment is disgraceful and then there are the reasons you've given below. This should not mean we just kludge everything together. A lot of stuff can be tidied up significantly and at least some of it can be thrown out. As such we should be working towards getting a new draft out that doesn't mean throwing out existing infrastructure but does allow for SIP/VoIP to move forward on the Internet not just corporate intranets. Of course getting IAX accepted as an Internet draft and moving everyone on it would probably be easier than fixing SIP :-) but you fight the (small) battles you can win. Sorry if this sounds like a rant. Regards, Andrew Radke Michael Kane wrote: > At the end of the day we all probably can get SIP and NAT to work together > if we spend TIME configuring our NAT boxes and SIP devices to negotiate the > traversal of a NAT. In the end result, the WAN IP must be is correctly > added to the contact table(sipd) or location table(SER), allowing the proxy > to route a call destined for that UA. Now, my delima as a service provider, > is how do I document this for every SIP device out there where my mother can > purchase a UA device, plug it in, and start placing calls without putting on > a poodle suit and jump through flaming hoops. That's why(for me) it becomes > an operational nightmare, not only to document vendor configs(if they > support NAT traversal), but, then support the end user on how to config > their devices. That why I have looked into(implemented) such technologies > like STUN and probably will be forced to purchase a SIP aware firewall that > will spoof and re-arrange SIP messages destined for my proxy server. > > > > Michael Kane > To-Talk Communications LLC. > 37 Sandusky Dr. > Wareham, Ma. 02571 > www.to-talk.com > 508-295-2826 |