[Serusers] Local ACKs for SER-SEMS

Bjorn Asmul bjorn at atlasvoice.com
Wed Nov 30 04:07:07 CET 2005


I'm using latest stable SER (0.9.5.pre2), and we have problems with a
Grandstream GXP-2000 phone with firmware 1.0.1.9.

We are trying to initiate a call from a Cisco gateway via SER to the
GXP.
SER tries to set up the call, but there seem to be an ACK missing
somewhere, so the Cisco keeps retrying the call.

>From the trace I could see this message:

sl_filter_ACK: to late to be a local ACK!

Would this patch fix this problem?

Also I did a re-compile from CVS (rev. rel_0_9_0) today.
Would this patch have been applied?

Thanks,
Bjorn

-----Original Message-----
From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of SER.Jan Janak
Sent: Tuesday, November 29, 2005 7:42 AM
To: Cesc
Cc: OpenSER-dev; SER-Users
Subject: Re: [Serusers] Local ACKs for SER-SEMS

Great, thanks a lot. I just commited your fix.

  Jan.

On 28-11-2005 18:51, Cesc wrote:
> Hi,
> 
> I found it ... now it works. There is a pseudo-patch at the end of the

> message (pseudo because it cannot directly be applied ... it is just 
> to mark the three lines i needed to change ... ). The patch is for
> ser-rel-0.9.4 (i send it to openser-devel ... i did not look, but 
> probably the problem is there too).
> 
> It is just a small bug ... from 0.9.0 to 0.9.4 a part of the loop was 
> moved outside the loop, to the end of the function ... and in a place 
> where there used to be a return now the loop would just continue ...
> Then, the matching_3261 function would, if a transaction matching the 
> ACK was found, would always return e2e ack ... even though the 
> ack_matching function returned it as a local transaction ...
> 
> For me, this patch fixes it ... but as it is a delicate part, i am not

> sure if it affects other parts ... i don't think so, but ...
> 
> Tks for all who took a look at the problem (greger, jan, samuel, ...
)!
> 
> Regards,
> 
> Cesc
> PS - This should affect anyone using SEMS ... so, if no one saw it ...
> does it mean there is really a few people using it? what a pitty ...
> 
> 
> Index: modules/tm/t_lookup.c
> ===================================================================
> --- modules/tm/t_lookup.c	(revision 8)
> +++ modules/tm/t_lookup.c	(working copy)
> 
> @@ -292,9
>  	struct via_body *via1;
>  	int is_ack;
>  	int dlg_parsed;
> -	int ret;
> +	int ret = 0;
>  	struct cell *e2e_ack_trans;
> 
>  	e2e_ack_trans=0;
>  	via1=p_msg->via1;
>  	is_ack=p_msg->REQ_METHOD==METHOD_ACK;
> 
> @@ -327,16
>  		if (is_ack && p_cell->uas.status<300 &&
e2e_ack_trans==0) {
>  			/* make sure we have parsed all things we need
for dialog
>  			 * matching */
>  			if (!dlg_parsed) {
>  				dlg_parsed=1;
>  				if (!parse_dlg(p_msg)) {
>  					LOG(L_ERR, "ERROR:
matching_3261: dlg parsing failed\n");
>  					return 0;
>  				}
>  			}
>  			ret=ack_matching(p_cell /* t w/invite */, p_msg
/* ack */);
>  			if (ret>0) {
>  				e2e_ack_trans=p_cell;
> +				break;
>  			}
>  			/* this ACK is neither local "negative" one, nor
a proxied
>  			 * end-2-end one, nor an end-2-end one for a UAS
transaction
> 
> @@ -358,9
>  	
>  	/* just check if it we found an e2e ACK previously */
>  	if (e2e_ack_trans) {
>  		*trans=e2e_ack_trans;
> -		return 2;
> +		return ret;
>  	}
>  	DBG("DEBUG: RFC3261 transaction matching failed\n");
>  	return 0;
>  }

_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list