[Devel] append_branch

[Klaus Darilion]

On Tue, February 6, 2007 19:04, Bogdan-Andrei Iancu said:
> Klaus Darilion wrote:
>> Bogdan-Andrei Iancu wrote:
>>> Hi Klaus,
>>>
>>> actually append_branch() does not store any path variable. Only
>>> registrar module sets it when doing lookup().
>>
>> Yes. But what happens if after lookup I call append_branch and add
>> another URI:
>> route  { lookup(); # sets RURI/DURI/PATH
>>          append_branch();
>>          rewriteuri("sip:foo at bar"); # this branch reuses
>>                                     # DURI and PATH from above
>>          t_relay();
>> }
>>
>> this one also will use the previous path - not?
>>
>> int append_branch(struct sip_msg* msg,....
>> {
>> ...
>>
>>         /* copy the path string */
>>         if (path && path->len && path->s) {
>> ...
>>
>> }
>>
> the new branch will not use the already set path as the script
> "append_branch" functions does not pass this parameter to the internal
> "append_branch" fct.

ok. guess I should have read the source code better :-)
thanks for clarifications.

>>> BTW, this lead to a related issue I found - stateless forward does
>>> not obey the path info.
>>>
>>> What you are saying about resetting the path after append_branch() is
>>> more related here to a logical issue: when creating a new branch (via
>>> append), all the info pushed into the new branch should be reset?
>>
>> Not sure how it should be done - probably I still do not know what
>> append branch exactly does. I try to write down my understanding of
>> branches and please correct me:
>>
>> When a request enters openser.cfg the message has one branch
>> (branches[0]).
>>
>> Any manipulation or lookup of RURI and DURI will be done on branches[0].
>>
>> If I call append_branch, the current RURI/DURI/PATH (identically to
>> branches[0]) will be copied into the next empty branch - in this case
>> branches[1].
>>
>> Then further URI/DURI manipulation will not touch branches[1] anymore.
>>
>> Is the above correct?
> yes, this is correct. The same applies for the branch flags and forced
> socket (along RURI, DURI and PATH)
>>
>> Thus IMO it would make sense to reset all parameters of branches[0] to
>> avoid confusion between the existing (copied into branches[x]) and the
>> fresh new branch.
> I agree, but note that there is no equivalent of branch[0]. all info for
> branch 0 is kept directly into the SIP request. The additional branches
> (>0) are kept in an array of branch structures.

Can you add a corrected version of my text to the core-parameters wiki
please?

> so, after doing append_branch(), all per-branch info from the request
> will be reset (following the above logic).

really? is this already the case? AFAIK, currently the DURI must be reset
manually.
>
> if we expand a bit the idea, it should be a different logic behind
> append_branch(); and append_branch(URI); :

btw: append_branch(URI) it not documented on the core wiki.

>     append_branch() - appends current branch[0] (RURI) as a new branch;
> the request must be reset after;
>     append_branch(URI) - appends a new URI as a new branch; this new URI
> should not inherit and reset anything from branch[0].

I agree. Will you apply this logic to 1.2?

regards
klaus

>
> regards,
> bogdan
>>
>> regards
>> klaus
>>
>> > like
>>> append_branch() will reset duri, bflags, path, forced socket ,leaving
>>> a new virgin branch 0 (ruri) to work with??
>>>
>>> regards,
>>> bogdan
>>>
>>> Klaus Darilion wrote:
>>>> Hi!
>>>>
>>>> AFAIK append_branch copies the current RURI, DURI and PATH into a
>>>> new branch. Then, if I push a new RURI I also have to delete the
>>>> previous DURI using resetdsturi(). Thus I guess we would also need a
>>>> function to reset the PATH too - don't we?
>>>>
>>>> regards
>>>> klaus
>>
>>
>
>