Juha Heinanen writes: > i think i found a problem with serial forking (both in lcr module and > core). the thing is that load_contacts/serialize branches does not > store the flags of branches into the avp. so after calling > next_contacts/next_branches flag information (e.g. on nat status of > contact) is lost.
after a bit more reading of the code, looks like it is not only flag information that is lost, but everything else except request uri and q value, i.e., flags, dst_uri, path, and socket. one way to solve this would be to introduce a separate avp for each missing piece of branch info, but that does not sound attractive. new branch info be invented requiring again new avp. the more i think about this, more convinced i get that serial forking should be integrated in tm module, i.e., each time when t_relay is called (perhaps with a new "serial fork" parameter), it would serve the next set of branches that have the highest q value and then mark those as served in dset.c branches array. that way all the info would be always present in branches array and there would be no need to save/clear/restore branches. comments? -- juha _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
