[Devel] local ACK from/to headers
Marco Holmer
holmer at comdasys.com
Mon Jan 22 09:12:05 CET 2007
Well, my workaround includes an additional parameter to build_local just
as the one for the from header which is quite painless as the function
is used only once in the code. I put that under control of a module
parameter, all rather simple but if anybody would be interested in a
patch (1.0.0 though) I am happy to share.
regards,
Marco
Eliot Gable schrieb:
> I noticed this problem, too. I came up with a workaround in my module
> code, but it creates a memory leak in the OpenSER base code.
>
> Eliot Gable
> Operations Engineer
> CCNA, CWNA, CWSP, Network+, Security+
> Broadvox, LLC
> 1228 Euclid Avenue
> Suite 390
> Cleveland, OH 44115-1800
> 216-373-4808
>
>
>
>
>> -----Original Message-----
>> From: devel-bounces at openser.org
>> [mailto:devel-bounces at openser.org] On Behalf Of Marco Holmer
>> Sent: Tuesday, January 16, 2007 9:41 AM
>> To: devel at openser.org
>> Subject: [Devel] local ACK from/to headers
>>
>> Hi developers,
>>
>>
>> Could someone shed some light on the creation of local ACKs:
>> why are the
>> To and From headers constructed differenty?
>> To header gets copied from the response to the parameter uas_to but
>> From header is taken from the transaction (the inital request's From
>> header).
>>
>> This results in a faulty From header in a case where rewritings are
>> configured (through textops) in both headers mentioned, where the ACK
>> should match the original Request. Would it not be easier to
>> copy both
>> headers from the arriving response?
>>
>> kind regards
>> Marco
>>
>>
>> ----
>> modules/tm/t_msgbuilder.c
>>
>> 183 char *build_local(struct cell *Trans,unsigned int branch,
>> 184 unsigned int *len, char *method, int
>> method_len, str *uas_to)
>> 185 {
>> 186 char *cancel_buf, *p, *via;
>> 187 unsigned int via_len;
>> 188 struct hdr_field *hdr;
>> 189 struct sip_msg *req;
>> 190 char branch_buf[MAX_BRANCH_PARAM_LEN];
>> 191 str branch_str;
>> 192 struct hostport hp;
>> 193 str from;
>> 194 str to;
>> 195 str cseq_n;
>> 196
>> 197 req = Trans->uas.request;
>> 198 from = Trans->from;
>> 199 cseq_n = Trans->cseq_n;
>> 200 to = *uas_to;
>>
More information about the Devel
mailing list