Hello,
I've got an AS5350 receiving calls on ISDN E1 and forwarding calls to OpenSER. At the moment ENUM translations are performed on the AS5350 and calls received by OpenSER already contain the correct SIP URIs.
Unfortunately I verified that the called party number information is lost in the process and at the called side I cannot distinguish numbers if I associate multiple PSTN numbers to the same sip user.
I guess this is Cisco's fault, since it should add a Remote-Party-ID of type "called" to the INVITE. Do I have to move ENUM mapping to OpenSER or is there a quicker solution?
thanks
Luca
Hi Luca,
if you cannot configure the Cisco GW to provide the original called number information, the logical solution is indeed to move the ENUM part on the proxy.
regards, bogdan
Luca Corti wrote:
Hello,
I've got an AS5350 receiving calls on ISDN E1 and forwarding calls to OpenSER. At the moment ENUM translations are performed on the AS5350 and calls received by OpenSER already contain the correct SIP URIs.
Unfortunately I verified that the called party number information is lost in the process and at the called side I cannot distinguish numbers if I associate multiple PSTN numbers to the same sip user.
I guess this is Cisco's fault, since it should add a Remote-Party-ID of type "called" to the INVITE. Do I have to move ENUM mapping to OpenSER or is there a quicker solution?
thanks
Luca
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Wed, 2007-04-11 at 11:26 +0300, Bogdan-Andrei Iancu wrote:
if you cannot configure the Cisco GW to provide the original called number information, the logical solution is indeed to move the ENUM part on the proxy.
I haven't yet been successful in finding any reference on this issue in the Cisco docs. Since the AS5350 is basically acting as B2BUA it may not be able to behave like I want it to.
If I understand the ENUM module docs correctly the ENUM lookup from OpenSER should replace the Request-URI while leaving the To header untouched, so that the call will be correctly routed to the SIP user, but will still preserve the information on the original called number. So manually adding a Remote-Party-ID header for the called number should not be needed.
ciao
Luca