On Thursday 09 June 2005 05:07 am, you wrote:

Just my 2 cents....

Since SER is transaction aware and not dialog aware, it is not easy to maintain consistent Cseq values during a dialog. I'm sure UAC maintainers are thinking on it and they will come with a solution, but just let them work without stress ;)

Sure. I didn't want to put stress on anyone. However I proposed a way to implement it by existing (or simple to add) means. Not that I liked it too much myself, but that is the only thing I could come with and I'd really like to receive some comments on whether it's possible or I'm completely wrong. Also I'm wondering how hard is it to have something like "save_dialog()" and "check_dialog()" function that would store callid and from/to tag in some in-memory hash. I don't think that performance/memory consumption objections really stands anymore. How much memory would it take to save dialog identifier (callid and tags)? Let's say 100 bytes. So if I dedicate 10M of RAM for that table I'd be able to keep 100000 dialogs.

However, don't think the UAC approach is the right one having TLS around......I would prefer pushing for TLS instead of adding a table of existing dialog in SER with the appropriate values. I'm sure there's lots of providers reading this list so if everybody starts asking for TLS....well, big providers will start providing it for auth. I'm not an expert but I've been told implementing TLS is not a hard job....;)

Well, if TLS becomes mainstream I'll have no choice, but use it, but I'd prefer to do without TLS or even moving to TCP, at least for a while. I believe existing md5 authentication is good enough for what it is used in SIP. Sure setting TLS is doable, but it's definitely more work then just setting shared password. Also I don't think TLS is going to become mainstream in SIP any time soon. Look at TLS in SMTP. It's been available for years, but I still don't see it in wide use for server-to-server communication, just between servers and end users.

Samuel.

Unclassified.

...

...

...

"Greger V. Teigre" greger@teigre.com 06/09/05 07:18AM >>>

Michael Ulitskiy wrote:

...

Greg, do you really believe that avoiding added, but optional complexity is good enough reason for not having IMHO necessary functionality?

Not at all. My point was that it is extremely important to add functionality where it belongs logically and where you can ensure that regular ser.cfg users are able to use the functionality without understanding the specs.

...

Again, IMHO, having something better than ip auth is a must in today's internet.

Again, I agree.

...

On the subject: I guess the reason is, as I said before, that not only cseq in original invite must be incremented, but cseq in all subsequent in-dialog messages must be adjusted (decremented for messages relayed to callee and incremented for messages relayed to called party). That is what, I guess, is hard to do in today's ser. I've posted my thoughts on how it possibly could be accomplished at http://lists.iptel.org/pipermail/serdev/2005-May/004589.html and haven't received any feedback or comments. I guess either there's a lack of interest for getting it to work which I guess is really strange or it's too hard to implement at current stage. As always any comments are welcome :)

I don't think it's a lack of interest or lack of need for it. All the developers are bombarded with requests and have long lists of core things to do. Sometimes its even hard to get them to evaluate and include patches in CVS. IMHO, increment cseq belongs in the UAC module (can do far too much harm if users play around with it). If you cannot get the maintainers attention, there is only one way: Get your hands dirty ;-)

g-)

---

Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev