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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers