9 Jun
2005
9 Jun
'05
5:07 a.m.
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 ;)
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....;)
Samuel.
Unclassified.
>> "Greger V. Teigre"
<greger(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev