[OpenSIPS-Users] Channing the FROM, is it a good idea?
Robert Thomas
thomcr at gmail.com
Sun Sep 11 04:30:03 CEST 2011
Hello List,
This question I think it's more related to SIP in general, or OpenSIPS -
Asterisk implementation that just opensips. However I highly value the
feedback and expertise of this list. I have the following scenario.
Customers -> OpenSIPS -> Asterisk Farm -> PSTN
I use my OpenSIPS for multiple reasons, authentication, billing,
authentication.
However the Asterisk servers see the source IP for all SIP traffic as the
Proxy and not the customer IP. Which for the most part is ok. However limit
the flexibility to the configuration, as I have to apply the same settings
to all customer "hidden" by the load balancer.
I could overwrite the FROM, to force asterisk to match a profile based on
the customer id, taken from an AVP. However Im worried about a few
implications.
Some of my customer deliver me Caller id on the FROM, Horrible I know, so I
copy it over to the PAI header and then manually parse the header in
asterisk.
Would overwriting the FROM cause any problems? Is it ok acording to SIP RFC
point of view? Would a SIP client freak out seen the FROM has changed on
the Sequential replies for the dialog.
If changing the FROM is not a viable solution, what other alternatives do I
have? Has anyone gone through this problem before and come up with some
clever solution?
And this is not just Asterisk related, it could theoretically be any
gateway. If there's a SIP proxy hiding the original Source IP/Port, which is
the most commonly used configuration to match SIP trunk profiles in almost
any equipment, then what can you use? What If I want to forbid a codec for a
particular customer.
I would be surprised if this issue has not come across an RFC or an
implementation, but I have not read all of them, not quite ;)
Thank you for your feedback in advanced.
--
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110910/ee377b5a/attachment.htm>
More information about the Users
mailing list