cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
975
Views
0
Helpful
6
Replies
Highlighted
Explorer

CUCM 8.6.1.20000-1 and SIP number manipulation

Hello,

we have a CUCM 8.6.1.20000-1 with a SIP trunk configured with a Destination Address XXX.XXX.XXX.XXX.

Outboung calls work fine.

Instead, inbound calls are dropped, because the other SIP device sends to CUCM a called number of this type: AAA@XXX.XXX.XXX.XXX.

At this moment, we cant't operate on the SIP device, so we have to find a workaround to strip somehow the "@XXX.XXX.XXX.XXX".

Is it possible?

TIA and regards.

6 REPLIES 6
Highlighted

Hello

What kind of SIP trunk have you set up ?

Normally the INVITE from the SIP device should be directed to AAA@CUCM_IP

If your SIP device has a strange behaviour, sending incorrect SIP messages, you need some kind of ALG between to do SIP manipulations.

Highlighted

Is the IP address wrong, is that why it has to be stripped?  Call Manager will only accept messages from sources that it has configured as destination addresses for SIP trunks kind of like an ACL.  Do you know why call manager is dropping or rejecting the INVITE in it's present form?

Highlighted

Hello,

we have corrected the issue on the SIP device; now, it sends calls with a called number of this type:

AAA@YYY.YYY.YYY.YYY

where YYY.YYY.YYY.YYY is the IP Address of CUCM.

However, now we have another issue on incoming calls: if the SIP device sends in the INVITE a P-Asserted-Identity of this type:

P-Asserted-Identity

the resulting CDR on CUCM is correct, with calling number "BBB".

Instead, if the P-Asserted-Type is of this type:

P-Asserted-Identity <>BBB@domain.ext>

the resulting CDR is incorrect, with calling number "@domain.ext".

What's wrong?

Highlighted

Hi,

What kind of trusted SIP device are you using ? Is it really a SIP endpoint or the requests are coming through a SBC ?

A better architecture description will help us to better understand your needs and possible points of failures.

However I think you need to manipulate incoming strings to remove what CUCM does not like or understand...On the SIP devices or somewhere onto the SBC realms.

No idea if it's a CUCM bug or not, as far as CDR are concerned.

Highlighted

Hello,

SIP device is actually a SIP proxy/B2BUA, so no SBC in the picture.

Regards.

Highlighted

Hi,

  I am having the same problem with CDR.

  CDR for ncoming calls from SIP trunk (SIP ISP -----> CUBE ------SIP----> CUCM 8.6) have @sip-server.c as callingpartynumber.

  Did you find any solution on that?

  Thank you