[Serdev] Re: [Serusers] how to increment cseq? (for uac auth)

[Michael Ulitskiy]

Greg, do you really believe that avoiding added, but optional complexity 
is good enough reason for not having IMHO necessary functionality?
Again, IMHO, having something better than ip auth is a must in today's internet.

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 :)

Michael

On Wednesday 08 June 2005 05:39 am, Greger V. Teigre wrote:
> 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 at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers 
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>