Hi Jan,
On Fri, Jul 24, 2009 at 11:07 AM, Jan Janak <jan(a)ryngle.com
<mailto:jan@ryngle.com>> wrote:
* enum - support for query on the originating
side, useful in PSTN
inbound processing
Could you send this patch to the mailing list and cc Juha?
Attached.... but... this is one of our crazy-experimental stuff. I
mean I haven't yet figured it our what to do with multiple response or
what is the final list of things to change in the message, so it looks a
bit messy to be merged in the master now.
As a bit of background info, this thing is useful when you have some
sort of PSTN access gateway that would proxy all calls towards a SIP
network. The node in charge of deciding the what-next part is called in
IMS related terminology a TRansit Control Function (TRC or TRCF) and I
have also attached a sample cfg for such a node. The advantage of doing
also enum_orig() is that this node can decide, based on ENUM
configuration, whether to trigger or not an originating leg processing
in an originating domain proxy. Or putting it in another way, this
provides the glue to have originating SIP services for PSTN UEs.
thanks for this interesting explanation.
It seems to me that it might make sense to allow the enum module to use
the select functions. This way the script writer could make enum queries
for all URIs in a SIP message. The only "issue" would be that after
querying the RURI you most likely would like to overwrite the existing
RURI with the result.
But if the result of the enum query would be stored in one or more AVPs
it could even be manipulated in the script before it overwrites the
existing RURI.
Juha what do you think?
If you dont want to do it would you accept a patch from me which
provides a new function for you enum module?
Cheers
Nils