Hello SER Team,
We are using SER as a SIP Server for our purpose. We wan to configure SER to
listen on two ports at the same time(i.e. 5060 & some other custom port such
as 5090 or something like that). Can you please assist us how can we achieve
this, means what changes we need to make such that
can t_check_trans() be also used to check if t_newtran() has been
called on the request earlier in the script?
if so, is it so heavyweight thing that it would be better to set a flag
when t_newtran() is called and then test the flag?
-- juha
___
SIP Ex
On Thu, Oct 7, 2010 at 9:16 AM, Andrei Pelinescu-Onciul
wrote:
> On Oct 07, 2010 at 15:52, Juha Heinanen wrote:
>> Andrei Pelinescu-Onciul writes:
>>
>> > > if proxy is processing all invites statefully, why anything needs to be
>> > > done when invite transaction corresponding the to cancel is m
Juha,
On Thu, Oct 7, 2010 at 8:52 AM, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
>> > if proxy is processing all invites statefully, why anything needs to be
>> > done when invite transaction corresponding the to cancel is missing?
>> > isn't it a case of unmatched cancel and the ca
On Oct 07, 2010 at 16:36, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
> > Sorry, it's slb.freply(), but you also need to send reason as str
> > (in auth_send_reply reason is char, but slb.freply() expects a str*
> > reason).
>
> thanks. i made the changes to auth_send_reply() and a
Thanks for the input, proxy-2 which is 3rd party sending early media without
SDP info in pregress message(180 or 183).
On Tue, Oct 5, 2010 at 7:47 PM, Andreas Heise
wrote:
> Hello,
>
> you could change the SDP with UPDATE method, but 183 must be send reliable
> in this case.
>
> regards,
> Andr
Andrei Pelinescu-Onciul writes:
> Sorry, it's slb.freply(), but you also need to send reason as str
> (in auth_send_reply reason is char, but slb.freply() expects a str*
> reason).
thanks. i made the changes to auth_send_reply() and after that
proxy_challenge()/www_challenge() worked ok both whe
On Oct 07, 2010 at 16:22, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
> > P.S.: changing www_challenge() would be trivial, but requires testing.
> > Only auth_send_reply() would need to be changed to use slb.send_reply()
> > and probably a module param. added to select between forced
Andrei Pelinescu-Onciul writes:
> P.S.: changing www_challenge() would be trivial, but requires testing.
> Only auth_send_reply() would need to be changed to use slb.send_reply()
> and probably a module param. added to select between forced stateless
> replies (lower processing) or auto replies.
Andrei Pelinescu-Onciul writes:
> The transaction are freed automatically in sr too, but the message is
> there to show a script bug (transaction created but no action taken, no
> forward, no reply, no release).
ok, that came because of the buggy www_challenge() that existed the script
without s
On Oct 07, 2010 at 15:52, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
> > > if proxy is processing all invites statefully, why anything needs to be
> > > done when invite transaction corresponding the to cancel is missing?
> > > isn't it a case of unmatched cancel and the cancel coul
On Oct 07, 2010 at 15:45, Juha Heinanen wrote:
> after playing with t_newtran(), i started to get these to syslog:
>
> Oct 7 15:39:11 sip /usr/sbin/sip-proxy[26119]: WARNING: tm
> [t_lookup.c:1543]: WARNING: script writer didn't release transaction
>
> as far as i remember, in k these messages
Andrei Pelinescu-Onciul writes:
> No, you need to send it by hand.
> At least with ser auth_db, I would:
> if (!www_authenticate()){
> ...
> if ($digest_challenge != "")
> append_to_reply("%$digest_challenge");
> sl_reply("401", "Unauthorized");
> }
can't do, because i don't w
On Oct 07, 2010 at 15:28, Juha Heinanen wrote:
> does www_challenge(realm, flags) know to send its challenge reply
> statefully or statelessly depending on if t_newtran() has been called or
> not?
No, you need to send it by hand.
At least with ser auth_db, I would:
if (!www_authenticate()){
Andrei Pelinescu-Onciul writes:
> > if proxy is processing all invites statefully, why anything needs to be
> > done when invite transaction corresponding the to cancel is missing?
> > isn't it a case of unmatched cancel and the cancel could just be
> > dropped?
>
> Well, IMHO it should be forwar
On Oct 07, 2010 at 15:22, Juha Heinanen wrote:
> in auth module readme, there is this kind of example code in
> section 1.3.3. nonce_count:
>
> # go stateful and catch retransmissions
> if (!t_newtran())
> drop; # retransmission
>
> based on tm source comment, the
On Oct 07, 2010 at 13:52, Juha Heinanen wrote:
> in tm readme there is this kind of example regarding use of
> t_relay_cancel:
>
> if (method == CANCEL) {
> if (!t_relay_cancel()) { # implicit drop if relaying was successful,
> # nothing to do
>
>
after playing with t_newtran(), i started to get these to syslog:
Oct 7 15:39:11 sip /usr/sbin/sip-proxy[26119]: WARNING: tm [t_lookup.c:1543]:
WARNING: script writer didn't release transaction
as far as i remember, in k these messages were not printed, because
transactions were freed automatic
does www_challenge(realm, flags) know to send its challenge reply
statefully or statelessly depending on if t_newtran() has been called or
not?
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router
in auth module readme, there is this kind of example code in
section 1.3.3. nonce_count:
# go stateful and catch retransmissions
if (!t_newtran())
drop; # retransmission
based on tm source comment, the #retransmission comment is not correct:
/** if no transaction
in tm readme there is this kind of example regarding use of
t_relay_cancel:
if (method == CANCEL) {
if (!t_relay_cancel()) { # implicit drop if relaying was successful,
# nothing to do
# corresponding INVITE transaction found but error oc
On Oct 07, 2010 at 10:57, Jiri Kuthan wrote:
> On 10/7/10 10:42 AM, Alex Balashov wrote:
> >Now that K v3.1.0 provides send_reply(), what is the preferred ideology
> >about whether to send stateful or stateless negative error replies?
> >
> >I mean in general, not in specific cases like digest au
On Sep 30, 2010 at 14:15, Rouskol Andrey wrote:
> Andrei,
>
> 30.09.10, 03:56, "Andrei Pelinescu-Onciul" :
> >
> > In the meantime I managed to reproduce it.
> > It should be fixed in all the versions now.
> >
> > Andrei
> >
> That's great! Because I could not reproduce this problem on s
On 10/07/2010 04:57 AM, Jiri Kuthan wrote:
The problem is that "somewhat increased" can be A LOT. transaction
context is in order of kilobytes and creating transaction context
on every single request can exhaust memory very very quickly.
It is not just about evil attacks but also about resilienc
On 10/7/10 10:42 AM, Alex Balashov wrote:
Now that K v3.1.0 provides send_reply(), what is the preferred ideology about
whether to send stateful or stateless negative error replies?
I mean in general, not in specific cases like digest authentication in the new
'auth' module, where, according t
Now that K v3.1.0 provides send_reply(), what is the preferred
ideology about whether to send stateful or stateless negative error
replies?
I mean in general, not in specific cases like digest authentication in
the new 'auth' module, where, according to the docs, a transaction and
stateful re
26 matches
Mail list logo
