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
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
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 withthe 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
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
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-)
On Thursday 09 June 2005 01:18 am, you wrote:
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.
Sure. I probably got you wrong. Sorry.
Again, IMHO, having something better than ip auth is a must in today's internet.
Again, I agree.
Perfect :)
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 ;-)
I agree. I wasn't at all going to argue that it logically belongs to UAC module. Well, I believe I did everything I could to give it a push. I'm a user, not a developer and I'm not sure that I can even get myself somehow familiar with ser codebase in a finite amount of time. I understand this is open-source, but I guess users entitled to make feature requests :)
g-)
Michael
-
Greger V. Teigre -
Juha Heinanen -
Michael Ulitskiy -
Stefan Sayer