I have some trouble on a specific configuration.
All my endpoints are registered on H.323 on DMA.
However I need to make SIP call to external solution through an RPAD.
On Resource manager, I have enabled SIP Routing through RPAD (also done for H.323)
On DMA, I created a specific dialrule.
However all sip calls failed directly on the dma
I have this on DMA : connect_sip_ext_address : sip:<sipuri>:5061
H.323 call works are properly forwarded to RPAD.
Did I missed something on my configuration
Version of DMA : 9.0.1_P2_Build_6134
Version of RPAD : 4.2.5_build_236400
Did you enable the SIP service on the DMA? If so, look under Reports, Call History for the SIP call. Then look at call details to see if there was an error message. This may indicate the next step to resolve this issue.
On the DMA I have the following error
Rejected : The dial string could not be resolved to an address.
What I don't understand here, is why the call is not transferred to RPAD.
In H.323 I don't have any issues
And there is port open from DMA to SIP Registrar, but it's the case between RPAD and sip registrar.
SIP signaling is enabled, and I specified specific routing on the resource manager to use "SIP Routing allowed via SIP aware SBC or ALG"
By default, the list of domains is empty under Call Server > Domains (for Domain Restriction). This means all domains are local. If you try to dial using a domain name, like firstname.lastname@example.org, it will not route to the RPAD because the DMA thinks t.plcm.vc belongs to the DMA. Therefore, you have to add the local domain, using the domain of the DMA to the list. Then it will forward all other domain dial strings out using the ALG defined in the site topology.
This is what I've thought but the list is not empty.
Also I tested the dialrule and it's properly match (resolve external address)
Also remember, my Group 310 are only registered in H323 to the DMA.
Do I need to add the RPAD as external sip peers on DMA ?
Yep - it should work as the DMA has a H323 to SIP conversion built-in. Future versions may see this disabled or removed as it provides limited conversion, no content. The admin guide should list all the features this doesn't support.
Can you post the call events to see how the DMA is processing the call. You should see the dial that the DMA found, possibility the dial by external networks one. The see what happens in the next couple of lines. Hopefully it is not a bandwidth issue as set in the site topology.
Here are the capture
I tried also using Rpad as external sip peer : it works however content sharing is not working (as stated on the admin guide). So it can't be an option for me ....
The capture shows the RPAD rejected the call. So I would look and share the call events from the call history on the RPAD. Another place I would look is in the RAS messages. You need to make sure the DMA is seting a Call Setup (CS) RAS message instead of a Location Request (LRQ) RAS message. An LRQ is used when neighbor H323 gatekeepers are trying to communicate. If the RPAD gets an LRQ, it will look at it's alias table and not find a match. This will cause the RPAD to issue a call reject.
There are other reasons why this would happen, but the above scenario is most likely in this scenario.