pua subs_info has
str* outbound_proxy; /* the outbound_proxy to use when sending the Subscribe request*/
but publ_info for publish requests does not have it? is there some good reason or just that no-one has needed it?
-- juha
I guess it was not needed, you can add it.
Cheers, Daniel
On 14/10/14 11:47, Juha Heinanen wrote:
pua subs_info has
str* outbound_proxy; /* the outbound_proxy to use when sending the ... request*/
but publ_info for publish requests does not have it? is there some good reason or just that no-one has needed it?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
I guess it was not needed, you can add it.
i added outbound_proxy to pua publ_info and modified send_publish to use it. then i thought to add outbound_proxy param also to pua_publish mi command, but it turned out that adding a new param would mean breaking backwards compatibility.
the only real solution that came to mind is switching from positional mi params to jason style name/value params. since that would be a rather big change, i tried to implement pua.publish rpc command, but was not able to figure how to map MI_ASYNC_RPL_FLAG to RPC_DELAYED_REPLY (if that mapping is possible at all).
-- juha
Daniel-Constantin Mierla writes:
I guess it was not needed, you can add it.
week or so ago i added outbound proxy to pua publ_info. i have also added ob proxy it to pua_mi pua_publish parameters, but have not yet committed the change, because it would break backwards compatibility.
what should i do:
1) commit the new version of pua_publish that adds the new ob proxy param
or
2) add a new mi command pua_publish_ob that is otherwise identical to current pua_publish, but has ob proxy param?
-- juha
On 04/11/14 13:57, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess it was not needed, you can add it.
week or so ago i added outbound proxy to pua publ_info. i have also added ob proxy it to pua_mi pua_publish parameters, but have not yet committed the change, because it would break backwards compatibility.
what should i do:
- commit the new version of pua_publish that adds the new ob proxy param
or
- add a new mi command pua_publish_ob that is otherwise identical to
current pua_publish, but has ob proxy param?
I don't have any particular reason to balance for 1 or 2.
But I think that if ob is added as last parameter, it can be interpreted as optional in the code, for both mi (parameters ->next being null or not) or rpc interfaces (using rpc scan with * modifier). So at the end pua_publish can be used as it is as well as with extra parameter for outbound proxy. Daniel
Daniel-Constantin Mierla writes:
But I think that if ob is added as last parameter, it can be interpreted as optional in the code, for both mi (parameters ->next being null or not) or rpc interfaces (using rpc scan with * modifier). So at the end pua_publish can be used as it is as well as with extra parameter for outbound proxy.
the problem is that pua_publish already has optional last param:
* body - The body of the publish request containing published information or missing if no published information. It has to be a single line for FIFO transport.
-- juha
two more alternatives:
1) module param that tells if pau_publish has ob proxy param
2) compiler define
this is a general policy issue: under what conditions can backwards compatibility be broken?
-- juha
IMO, compile define is not a good option, module parameter is better.
I thought of optional parameter in case of being something easy to add. It is no backwards compatibility restriction for adding to master (to be in 4.3), my opinion was more for trying to be friendly to old versions. In that direction, looks like pua_publish_ob would be a solution.
However, I am fine with having an incompatible version in the next major release -- it has to be documented in the upgrade guidelines.
If there are no other people having particular preferences on this topic to be discussed here, it is up to you how you want to proceed.
Daniel
On 04/11/14 14:57, Juha Heinanen wrote:
two more alternatives:
module param that tells if pau_publish has ob proxy param
compiler define
this is a general policy issue: under what conditions can backwards compatibility be broken?
-- juha