[Serusers] Local ACKs for SER-SEMS

Greger V. Teigre greger at teigre.com
Wed Nov 23 08:17:18 CET 2005


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 at gmail.com>
To: "SER-Users" <serusers at lists.iptel.org>
Sent: Wednesday, November 16, 2005 11:13 AM
Subject: [Serusers] Local ACKs for SER-SEMS


> 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 at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
> 




More information about the sr-users mailing list