Re: [reSIProcate-users] B2BUA hiding support of REFER/replaces to "external" SIP elements, but exposing to "internal" ones
Thanks Scott.
I had originally prototyped something similar, but had kept the automatic advertisement and was attempting to *remove* the REFER method from the list of Accepted methods (and "replaces" from the list of Supported extensions) in the onReadyToSend().
From what I have inferred from the code, upon receiving a request, the method is always validated against the MasterProfile's list of supported methods (see DUM::validateRequestURIMethod()), So, the B2BUA application must still indicate that REFER is a supported method (master profile) so the internal SIP elements can initiate REFER requests. This also means that the B2BUA application code also has to handle sending back the 405 Method Not Allowed responses if we ever received a REFER request from an external SIP element (and send back a 420 Bad Extension if we ever received an INVITE with replaces from an external SIP element) - i.e., since there is no way to ensure that the far end application will actually respect our advertised methods/extensions ;-).
It may be cleaner to turn off the automatic advertisement and have the B2BUA application code build the "Allow" and "Supported" headers rather than to dissect the automatically created ones. So, I will write up the code for that and see how it looks.
Regards,
Jim
On Wed, Jul 31, 2013 at 11:07 AM, Scott Godin
<sgodin@xxxxxxxxxxxxxxx> wrote:
You are correct - there is only one copy of the settings stored in the Master Profile per dum instance. The only thing I can thing of is that you can disable the automatic advertisement of Supported and other headers and use a Message Decorator or another mechanism (https://www.resiprocate.org/Modifying/Decorating_messages_sent) to add the required headers on messages on one side only.
Scott
Hi,
We are developing a B2BUA using DUM that sits between "external" and "internal" SIP elements.
External Internal
SIP <------> B2BUA <--------> SIP
Elements Elements
We want to advertise to the "internal" SIP elements that we support REFER and "replaces", but do not want to advertise REFER and "replaces" to the "external" ones.
From what I can tell in the code, the "Allow" and "Supported" headers are automatically filled in by the single "MasterProfile" that is bound to DUM - regardless of the UserProfile that is assigned to the DialogSet via selectUASUserProfile().
I'd rather not have to deal with 2 DUM instances and would like to find a way to have a single DUM expose different supported methods depending on whether the B2BUA is communicating with an internal or external SIP element.
Am I missing something or is this not possible currently with a single DUM instance?
Thanks,
Jim
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/