8 Jun
2005
8 Jun
'05
5:05 a.m.
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
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
1:26 p.m.
New subject: [Serdev] Re: [Serusers] how to increment cseq? (for uac auth)
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
9 Jun
9 Jun
1:18 a.m.
New subject: [Serdev] Re: [Serusers] how to increment cseq? (for uac auth)
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-)
2:31 p.m.
New subject: [Serdev] Re: [Serusers] how to increment cseq? (for uac auth)
On Thursday 09 June 2005 01:18 am, you wrote:
Perfect :)
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 :)
Michael Ulitskiy wrote:
Sure. I probably got you wrong. Sorry.
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-)
Michael
7152
days inactive
7153
days old
5 comments
4 participants
participants (4)
-
Greger V. Teigre -
Juha Heinanen -
Michael Ulitskiy -
Stefan Sayer