23 Nov
2005
23 Nov
'05
11:53 a.m.
Actually I've seen the mail but did not have yet time to look into it
(I have it on my todo list).
When communicating with applications like sems over the fifo or unix
sockets, SER takes care of ACK processing (that also means generating
local e2e ACKs on behalf of sems). This is a hack because tm has to do
all the dialog-related logic (such as route processing, loose/strict
routing and so on).
Inside tm end-to-end ACKs are matched with the original INVITE
transaction. This was needed for accounting purposes, if I recall it correctly.
In any case full tm traces would be helpful, especially for P3.
Jan.
On 23-11-2005 10:38, Cesc wrote:
Hi Greger,
First, the last half of your email ... i cannot run a dedicated
instance of SER. We run an embedded system, thus not much space and
power to spare.
As for the NAT ... we have no NAT in our network (lucky us :D ).
As for the first part ... i had not seen a response either :)
Actually, i lost the email in gmail folders, could not find it
anywhere ... tks for replying, now i found it again.
As for the ACK ... i tried using t_lookup_request ... it turns out
that it does find a transaction, but it identifies them as e2e (i
guess ... end2end) ... i will investigate further ... and i will
provide a trace.
Tks!
Cesc
On 11/23/05, Greger V. Teigre <greger(a)teigre.com> wrote:
Hi Cesc,
I haven't seen a response to your post?! Are you sure the ACKs are not
caught by loose routing?
I would suggest setting up a separate ser instance on ex. port 5062 and
dedicate it to sems interfacing. Then in your main ser you just correctly
forwards the INVITEs to the sems ser instance. Also remember to run
fix_nated_sdp("3") for NATed clients (SEMS support active media. Both sems
and SER-SEMS should run on a public IP.
g-)
----- Original Message -----
From: "Cesc" <cesc.santa(a)gmail.com>
To: "SER-Users" <serusers(a)lists.iptel.org>
Sent: Wednesday, November 16, 2005 11:13 AM
Subject: [Serusers] Local ACKs for SER-SEMS
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Hi,
In my lab we have SER (0.9.4) running, collocated in the same box with
SEMS, communicating via the fifo.
An abstraction of the config:
//identify traffic for SEMS
//send to route[x]
route[x] {
if( !t_newtran() ) { ..... }
if( method == "ACK" ) { break;} //drop local acks ...
t_reply("100", "msg");
send via fifo to sems ...
}
I have stumbled against some problems:
P1) Local ACKs from the phone are not being dropped.
P2) to-tag in replies from SER from sl_send_reply and OK message change
P3) the t_newtran does not stop sending OKs, even it receives ACKs to them
They all seem to be related ...
the ACK from the phone back to SER, which are local(right?), are not
dropped for two reasons: the sl_timeout is not updated, as i don't
have an sl_send_reply in the route[x] block.
I can fix the above by adding an sl_send_reply("183", "sems session in
progress") ... but then, the second problem appears.
Adding the sl_send_reply(183, ) adds a to-tag to the 183-reply, but
then the following OK has a completely different to-tag ... which is
the one used by my UA to create the ACK. As the to-tag in the ACK is
different to that from the 183-reply ... the sl_filter_ack does not
recognize the ACK as local, and does not filter it.
In any case, this would not solve the problem of the t_newtran sending
OK replies to the phone, even it receives ACKs to them.
What can i do? should i use t_release somewhere? are these ACKs
"local"? if not, where should these ACKs be routed to, to the route[x]
block?
Tks in advance,
Cesc
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers