8 Jun
2005
8 Jun
'05
5:39 a.m.
A bit of context:
We have at ONsip.org tried to document how to get started with SER and one
of the things that I'm worried about is all the advanced (special purpose)
functionality that has been and (probably increasingly) will be necessary to
add to SER and its modules. The more options like this, the more ways
people can really f... up their config. One of the big concerns right now
is how to ensure interoperability, not on a message level (where SIP has
proven quite interoperable), but on the message flow level. I believe there
are MANY non-conforming ser.cfgs out there that actually work, but have
hidden time bombs ready to go off when new equipment is added or new
functionality added. I think the interesting ENUM discussion on serdev is a
case in point (especially with some of the suggestions for solutions).
ser.cfg is an extremely powerful configuration script language and with
the exposure of (does anybody know how many?) functions with various
options, there are plenty of ways to go wrong.
This is why we have tried to establish the example configuration files
as "Best Practice", i.e. validated to conform with the RFCs. So far, we are
pretty happy with the feedback and over time they will hopefully be
well-established as reference "designs."
To the CSeq question:
I agree fully with Juha that this is something that belongs in the UAC
module, not as a separate function. Thus, this is a request to the
maintainer (I suggest using serdev). I suspect there is reason for why CSeq
has not been incremented since this fact is duly documented (instead of
implemented). However, I do not know the reason.
g-)
Stefan Sayer wrote:
Hello,
is there a simple method to increment CSeq of a branch?
I have the following in failure_route:
if (uac_auth()) {
# mark that auth was performed
setflag(7);
# trigger again the failure route
t_on_failure("3");
# repeat the request with auth response
append_branch();
----------> and here I'd like to increment CSeq
t_relay();
}
If CSeq is not incremented, this authenticated request does not work
with RFC strict UAs, as discussed eg in this
(http://lists.iptel.org/pipermail/serusers/2005-May/019806.html)
thread.
Now as I want to proxy auth an INVITE I am sending myself from sems I
could do a dirty workaround: assume that the INVITE needs two CSeqs
and increment cseq a second time for subsequent requests in sems.
This is of course a hack but would save me from implementing auth in
sems for the moment.
Thanks for any suggestions
Stefan
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers