I was going through the source code of SER to implement REGISTER METHOD. Is there anyone already implementing this functionality?
Kannaiyan
SER is a very good SIP proxy. A proxy sets up calls, doesn't terminate
No doubt in that.
I really don't want that to be a SIP Proxy feature. But to add as a module like NAT, RTPProxy. I hope it is clear.
The reason why it is needed: I cannot buy bulk of phones to have a phone for every sip proxy or even to pay too much for every additional sip uri. I feel it would be better to be done at the server side rather than at the sip endpoint.
Asterisk needs a loads of changes to have the same implementation compared to SER.
Kannaiyan
----- Original Message ----- From: "Olle E. Johansson" oej@edvina.net To: "Jan Janak" jan@iptel.org Cc: serusers@lists.iptel.org Sent: Friday, January 09, 2004 7:41 PM Subject: Re: [Serusers] REGISTER implementation --
On Friday 09 January 2004 21:20, Kannaiyan Natesan wrote:
SER is a very good SIP proxy. A proxy sets up calls, doesn't terminate
No doubt in that.
Thanks :-)
I really don't want that to be a SIP Proxy feature. But to add as a module like NAT, RTPProxy. I hope it is clear.
Most of SERs features are implemented as modules, but i guess Ole meant, that sending REGISTERs is a feature which belongs to endpoints and not to a proxy which is not able to place or answer calls. And i agree with that. (For the implemenation of such a feature: hwo to you want to manage all the passwords, accounts, etc. at the server.. sounds horrible to me.)
A little analogy: would you tell you SMTP server how it can fetch the mail from you several mail accounts? I guess not. Either you use a MAU which can handle several accounts. Or you use forwardings, to collect all your mails at one central account.
=> Either use SIP clients which can handle several accounts, or forward you other accounts (by inserting persistent contacts to your central account) to one central account. (And please dont blame us, if you use accounts at servers which can not forward your account :-)
Asterisk needs a loads of changes to have the same implementation compared to SER.
:-)
Regards Nils
(For the implemenation of such a feature: hwo to you want to manage all
the
passwords, accounts, etc. at the server.. sounds horrible to me.)
I really don't think there is much think to be stored for a single user. Username: password: proxy: portno: Which is not really tough though as by the SER DB modules.
If my remote SMTP server is not forwarding the email address, then If I receive a trigger that a email is received on that account, I can POP and send it again to my local SMTP server. I think there is an acceptable logic in this.
With respect to the Registration I think only the "REGISTER" sip message need to be to send to the register module, rest of the call sequences we can make to handle by SER. right?
Regards, Kannaiyan
Asterisk needs a loads of changes to have the same implementation
compared
Nils Ohlmeier wrote:
Why not start with Nils' toy SIPSAK and build a client that registers and then forwards INVITES to your client? A command line function like what Kannaiyan describes in SIPSAK would be a perfect tool.
Thank you, Nils, for the mail server analogy. There are tons of tools to fetch mail from several mail accounts and forward to your mail account. None of them are postfix or sendmail modules.
/O
On Friday 09 January 2004 22:03, Olle E. Johansson wrote:
Yes, it should be easily possible to extend sipsak to use a given Contact (the contact address of the "central merging" server) during a registration run. Then you can run it from a web page, cron job, or whatever to forward your calls to the given Contact.
That's what i meant: AFAIK there is no mail server available which speaks POP and/or IMAP (Note: i'm not very familiar with the bulk for the M$ OSs).
Greets Nils
On Friday 09 January 2004 22:12, Nils Ohlmeier wrote:
Added to the To-Do list (web page and CVS).
Note: i currently do not plan to add a config file option for sipsak to support multiple accounts. So you would have to call it from a script with the stored account informations. But i would probably not reject a patch for a config file :-)
Greets Nils
-
Jan Janak -
Kannaiyan Natesan -
Nils Ohlmeier -
Olle E. Johansson