05-21-2018 06:26 AM - edited 03-18-2019 12:25 PM
I have an existing SIP service provider, through which all our calls in and out over 60 trunks work perfectly. This ITSP does not use registration or authentication and does not require us to do any header manipulation. They have been our provider for about 5 years. Having recently dropped our ISDN backup telephony service we now have a second ITSP to provide call functionality on alternate number ranges in the event the primary ITSP should fail.
The new ITSP uses registration and authentication, so our previously very simple sip-ua config ( retry invite 3 and timers trying 350) now has many more commands in it. They also require us to employ a copylist and a sip profile to modify the inbound INVITE from them in order to make inbound calls work.
Inbound calls land on the CUBE, are picked up by the correct WANside incoming dialpeer, are matched to the correct LANside outgoing dialpeer, but only if I don't include the outbound dialpeer level sip profile command below. Calls are dropped with a 'no matching outbound dialpeer' message. If I remove the sip profile command, calls go through, but only to the trunk number as the ITSP requires header manipulation.Only the trunk registered number makes it to CUCM, no matter what number from the new range is dialled.
The relevant config is:
dial-peer voice 16 voip
description * INBOUND WANside *
session protocol sipv2
incoming called-number 44152456798.
voice-class sip copy-list 1
dtmf-relay rtp-nte
codec g711alaw
no vad
voice class sip-copylist 1
sip-header TO
dial-peer voice 17 voip
description * BACKUP OUTBOUND LANside to CUCM *
translation-profile outgoing PSTN_inbound
destination-pattern 44152456798.
session protocol sipv2
session target ipv4:10.42.26.72
voice-class sip profiles 1
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
no vad
voice class sip-profiles 1
request INVITE peer-header sip TO copy "sip:(.*)@" u01
request INVITE sip-header SIP-Req-URI modify ".*@(.*)" "INVITE sip:\u01@\1"
voice translation-profile PSTN_inbound
translate calling 4
translate called 3
voice translation-rule 3
rule 7 /^4415245\(6798.\)/ /\1/
voice translation-rule 4
rule 1 // /8/
#test voice translation-rule 4 441524567988
Matched with rule 1
Original number: 441524567988 Translated number: 8441524567988
is-sipgw02-b18#test voice translation-rule 3 441524567988
Matched with rule 7
Original number: 441524567988 Translated number: 67988
My main question then, if the translation can be seen to be working by 'test voice translation-rule 3' then how come 67988 is not passed to CUCM, and instead only 67980 from the INVITE is passed. In what way does the translation profile we're used to using with the main ITSP not work with the sip profile demanded by the new ITSP? Is the regex for the profile incorrect?
Thanks
Nathan.
Debug snippet
Received:
2426867: May 10 20:52:08.248: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
INVITE sip:441524567980@217.114.51.210:5060 SIP/2.0
Via: SIP/2.0/UDP 83.218.143.16:5060;branch=z9hG4bKsghogr20cg3hd7h1v2e1.1
Max-Forwards: 15
From: <sip:07814965714@87.224.0.9>;tag=B61DcrZmgZ08g
To: <sip:441524567988@83.218.143.22>
Call-ID: 76b48670-cf2e-1236-1c9d-5065f3f05b98
CSeq: 122654900 INVITE
Contact: <sip:07814965714@83.218.143.16:5060;transport=udp>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 275
X-FS-Support: update_display,send_info
Remote-Party-ID: <sip:07814965714@87.224.0.9>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1525959014 1525959015 IN IP4 83.218.143.16
s=FreeSWITCH
c=IN IP4 83.218.143.16
t=0 0
m=audio 57594 RTP/AVP 8 0 18 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
2426934: May 10 20:52:08.252: //-1/74C2DC6BA525/DPM/dpAssociateIncomingPeerCore:
Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=16
2427001: May 10 20:52:08.252: //-1/xxxxxxxxxxxx/SIP/Info/critical/12288/sipSPICreateNewRawMsg: No Data to form The Raw Message
cisco-username=07814965714
----- ccCallInfo IE subfields -----
cisco-ani=07814965714
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=441524567980
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
2427007: May 10 20:52:08.256: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_PROCEEDING cisco-username=07814965714
----- ccCallInfo IE subfields -----
cisco-ani=807814965714
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=67980
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
Solved! Go to Solution.
05-22-2018 05:13 AM
Great stuff. Can you send the traces for the cancelled call that is not working. This is most likely an issue with your provider. As you can see the call works when CUCM registred phone hangs up the call.
Dont forget to rate the posts as well or mark as answered :)
05-22-2018 07:02 AM
I think I've exported the right bits in TransX in the attachment. I made a call from 07814965714 to DN 67988 (the new ITSP), and hung up, but the CANCEL doesn't seem to get through.
I made another call from 07814965714 to DN 95219 (our existing ITSP) and this call CANCELed appropriately and as expected.
They should appear back-to-back in the txt files attached. The CANCEL messages look quite different from the two ITSPs which leaves me wondering if there's something I now need to add to the CUBE config so it understands both.
05-22-2018 07:41 AM
please turn off all debugs. Enable only debug ccsip message. do the test again and include call details
05-22-2018 07:57 AM
I got luck y with the messaging on this one, no other calls came in or out over these few seconds.
I hung up the mobile (07814965714) inbound end of the call from the PSTN at 15:47:48 and then lifted and replaced the receiver on the desk phone at 15:47:59.
Does that help? Is that you mean by call details?
05-22-2018 08:20 AM
The ITSP is sending the CANCEL.
2568235: May 22 15:47:48.997: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:441524567980@217.114.51.210:5060 SIP/2.0
Via: SIP/2.0/UDP 83.218.143.16:5060;branch=z9hG4bK550s4g30bo60s49ai470.1
CSeq: 123164165 CANCEL
Max-Forwards: 15
From: <sip:07814965714@217.13.128.11>;tag=y5cyppXHDmyZm
To: <sip:441524567988@83.218.143.24>
Call-ID: ea0abdf3-d871-1236-41bd-94188268d190
Content-Length: 0
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
CUBE is sending 481
2568261: May 22 15:47:49.001: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP 83.218.143.16:5060;branch=z9hG4bK550s4g30bo60s49ai470.1
From: <sip:07814965714@217.13.128.11>;tag=y5cyppXHDmyZm
To: <sip:441524567988@83.218.143.24>
Call-ID: ea0abdf3-d871-1236-41bd-94188268d190
CSeq: 123164165 CANCEL
I dont see the call leg between the CUBE and CUCM? Is this not using a SIP trunk?
Can you also ensure that your turn off debug ccsip info
On the gateway do
un all
debug ccsip mess
05-23-2018 02:40 AM
Sorry for being a dim there with the 'un all' command Ayodeji.
In thinking about this a bit more, the CANCEL coming from the ITSP is for the number in the original, unmodified INVITE, which is the number that the trunk to the ITSP is registered with 441524567980. But the CUBE has already modified that to whatever number is specified in the To field by using the WANside inbound dialpeer sip-profile. So can it be the case that the ITSP is trying to cancel a call with one number when the CUBE is looking for a call with another number, hence CUBE sending back 481? Perhaps I'd need to copy the To: field to the CANCEL: field on the inbound WANside dialpeer, as well as copying to the To: to INVITE as is already being done.
I see what you mean about the LANside leg of the call not being visible in the messages too. It's definitely a SIP trunk; config clip from the outbound LANside dialpeer:
session protocol sipv2
session target ipv4:10.42.26.72
I'll keep looking at this in the meantime and see about giving this idea on CANCEL header manipulation a try.
Many thanks
Nathan.
05-23-2018 02:47 AM
05-23-2018 02:51 AM
05-23-2018 03:15 AM
Great stuff, thats a great find, thanks for posting it
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide