Someone else approached me at Fosdem (iirc), saying they are working on (or already have) a module to deal with SIP-I, but it may not actually happen to get it from there (unless the person is here and can confirm more).

Anyhow, adding in a new module is ok as long as there is a maintainer for it in the first year. Most of my modules were added because I needed them, not because there was another potential user. In this case, as said above, I expect more to use it, but that does not matter at the end. So I would find it useful to have.

Just for sake of completeness, besides the maintainer rule, the only constraint for modules would be not to be something very specific just for a private use case (e.g., a connector to an internal system, not available to others at all, with custom protocol and no chance for additional use cases). Not the case here, of course, being actually about a recognized standard.

Cheers,
Daniel


On 3/22/13 3:27 PM, Alex Balashov wrote:
Yes, but what happens when those modifications, or responses based on those 
modifications, are returned to the sender? Much as with most SIP headers, the sending SS7 
gateway can well say, "I didn't send that."


Javi Gallart <[email protected]> wrote:

Thanks Alex

the first thing that came to my mind is performing some number
manipulation. Imagine kamailio acting as a router for several carriers.

One of them demands an international NOA with a weird prefix, whereas
the other one, for the same destination, requires a pound (#) at the
end, and so on. I agree with you in disliking idea of being too
"invasive" in the body of the sip message, but it's something already
doable for instance with SDP.

Javi
On 03/22/2013 02:50 PM, Alex Balashov wrote:
Hi Javi,

The first question to ask is: if Kamailio could understand ISUP
parameters, what would it do with them?

If the answer is "not a whole lot", chances are it is something that
only needs to be understood by the endpoints, and which Kamailio
would
continue to be agnostic to, as it is now.  Kamailio is, above all
else, a message relay.

-- Alex



_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
 - http://conference.kamailio.com -


_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to