Is your Remote-Party-Id different from your From header?
Please post your full SIP INVITE so we see what your headers look like. You cant match uri based on RAI, but ideally your From and RAI should be the same..
... View more
Thats your answer right there. You can use uri dialing to match an inbound dial-peer if the calling number is a certain number and you can then apply voice translation rule to change the called number.
### Configure voice class uri to match the from field ++
voice class uri 500 sip pattern firstname.lastname@example.org
##configure translation rule to change the called number to what you want
voice translation-rule 500 rule 1 /^\(.*\)/ /919191/
voice translation-profile test
translate called 500
## configure dial-peer to match the calling number 2222, apply the sip uri and translation profile## dial-peer voice xxx voip translation-profile incoming test session protocol sipv2 incoming uri from 500
... View more
Using the IF logic feature of SIP profile will not work for your scenario. This can only be used to add a SIP header it cant be used to modify a header. In your Scenario you are looking for a way to modify the RURI based on a specific calling number.
... View more
The response to this was already posted in the original post you raised. Have you tried the suggestion there. This parameter has nothing to do with INVITEs you are receiving with @domain. Have you added the domain to your cluster fully qualified domain as suggested in the other post?
... View more
Here is my analysis of what I see..
++After the first call is established to extension 2001 from AA , the phone presses the transfer button++
+++ To signal the transfer, the IP phone sends a RE-INVITE to the gateway with sendonly attribute ++
008853: Feb 6 13:31:40.353: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:email@example.com:5060 SIP/2.0 Via: SIP/2.0/UDP 10.127.4.2:5060;branch=z9hG4bK711860f0 From: <sip:firstname.lastname@example.org>;tag=8478ace600a8000a7d03e2ca-10898e03 To: <sip:email@example.com>;tag=1F089FA8-5FF Call-ID: A32A6A6C-A8911E8-AD5FA7C6-B26F15DB@10.127.4.250 Max-Forwards: 70 Date: Fri, 01 Jan 1982 00:09:38 GMT CSeq: 102 INVITE User-Agent: Cisco-CP8961/9.4.2 Contact: <sip:B0A0-D76@10.127.4.2:5060;transport=udp> Accept: application/sdp ---- v=0 o=Cisco-SIPUA 5461 1 IN IP4 10.127.4.2 s=SIP Call t=0 0 m=audio 17818 RTP/AVP 0 102 9 124 8 116 18 101 c=IN IP4 10.127.4.2 ---- a=sendonly
+++ Next the gateway sends 200 OK with recvonly ++
008855: Feb 6 13:31:40.355: //45248/9FF9D520AD57/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.127.4.2:5060;branch=z9hG4bK711860f0 From: <sip:firstname.lastname@example.org>;tag=8478ace600a8000a7d03e2ca-10898e03 To: <sip:email@example.com>;tag=1F089FA8-5FF Date: Tue, 06 Feb 2018 13:31:40 BRV Call-ID: A32A6A6C-A8911E8-AD5FA7C6-B26F15DB@10.127.4.250 CSeq: 102 INVITE ---- Server: Cisco-SIPGateway/IOS-15.5.3.M6a Supported: timer Content-Type: application/sdp Content-Length: 190 v=0 o=CiscoSystemsSIP-GW-UserAgent 863 9070 IN IP4 10.127.4.250 s=SIP Call c=IN IP4 10.127.4.250 t=0 0 m=audio 25014 RTP/AVP 0 c=IN IP4 10.127.4.250 a=recvonly a=rtpmap:0 PCMU/8000
+++ Next gateway sends RE-INVITE to phone with recvonly +++
008857: Feb 6 13:31:40.363: //45248/9FF9D520AD57/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:B0A0-D76@10.127.4.2:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.127.4.250:5060;branch=z9hG4bK1D0DED9 Remote-Party-ID: <sip:firstname.lastname@example.org>;party=calling;screen=no;privacy=off From: <sip:email@example.com>;tag=1F089FA8-5FF To: <sip:firstname.lastname@example.org>;tag=8478ace600a8000a7d03e2ca-10898e03 Date: Tue, 06 Feb 2018 13:31:40 BRV Call-ID: A32A6A6C-A8911E8-AD5FA7C6-B26F15DB@10.127.4.250 -- Contact: <sip:email@example.com:5060> Expires: 180 Allow-Events: kpml, telephone-event Content-Type: application/sdp Content-Length: 190 v=0 o=CiscoSystemsSIP-GW-UserAgent 863 9070 IN IP4 10.127.4.250 s=SIP Call c=IN IP4 10.127.4.250 t=0 0 m=audio 25014 RTP/AVP 0 c=IN IP4 10.127.4.250 a=recvonly a=rtpmap:0 PCMU/8000
++ and here is where the issue is. The phone sends 200 ok with SDP without any of the following:
M-line, connection info, and codec attributes advertised ++
008858: Feb 6 13:31:40.391: //45248/9FF9D520AD57/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.127.4.250:5060;branch=z9hG4bK1D0DED9 From: <sip:firstname.lastname@example.org>;tag=1F089FA8-5FF To: <sip:email@example.com>;tag=8478ace600a8000a7d03e2ca-10898e03 Call-ID: A32A6A6C-A8911E8-AD5FA7C6-B26F15DB@10.127.4.250 Date: Fri, 01 Jan 1982 00:09:38 GMT CSeq: 103 INVITE Server: Cisco-CP8961/9.4.2 Contact: <sip:B0A0-D76@10.127.4.2:5060;transport=udp> Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO Remote-Party-ID: "RECEPCAO ACCINFRA - 2902" <sip:firstname.lastname@example.org>;party=called;id-type=subscriber;privacy=off;screen=yes ---- Content-Length: 65 Content-Type: application/sdp Content-Disposition: session;handling=optional v=0 o=Cisco-SIPUA 15183 2 IN IP4 10.127.4.2 s=SIP Call t=0 0
---------- The parameters below are all missing------------
m=XXX c=XXX a=XXX a=rtpmap:0 PCMU/8000
+++ Next gateway sends an ACK to 200 Ok followed immediately by a BYE ++
008859: Feb 6 13:31:40.393: //45248/9FF9D520AD57/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:B0A0-D76@10.127.4.2:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.127.4.250:5060;branch=z9hG4bK1D0E24DA From: <sip:email@example.com>;tag=1F089FA8-5FF To: <sip:firstname.lastname@example.org>;tag=8478ace600a8000a7d03e2ca-10898e03 Date: Tue, 06 Feb 2018 13:31:40 BRV Call-ID: A32A6A6C-A8911E8-AD5FA7C6-B26F15DB@10.127.4.250 Max-Forwards: 70 CSeq: 103 ACK Allow-Events: kpml, telephone-event Content-Length: 0
+++ BYE ++ 008862: Feb 6 13:31:40.393: //45248/9FF9D520AD57/SIP/Msg/ccsipDisplayMsg: Sent: BYE sip:B0A0-D76@10.127.4.2:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.127.4.250:5060;branch=z9hG4bK1D0FD12 From: <sip:email@example.com>;tag=1F089FA8-5FF To: <sip:firstname.lastname@example.org>;tag=8478ace600a8000a7d03e2ca-10898e03 Date: Tue, 06 Feb 2018 13:31:40 BRV Call-ID: A32A6A6C-A8911E8-AD5FA7C6-B26F15DB@10.127.4.250 User-Agent: Cisco-SIPGateway/IOS-15.5.3.M6a Max-Forwards: 70 Timestamp: 1517931100 CSeq: 104 BYE Reason: Q.850;cause=65 P-RTP-Stat: PS=330,OS=52800,PR=324,OR=51681,PL=0,JI=0,LA=0,DU=6 Content-Length: 0
+++ Summary +++
This looks to be an issue with the SIP phone not processing the RE-INVITE with recvonly media direction properly. My first suggestion will be to upgrade the firmware on the phone and test again
... View more
First of all your telco is disconnecting the call and they are right to. Rajan mentioned that CUBE send multiple 180 ringing and here is an additional info to that
+++ CUBE sends 180 ringing but wants to do PRACK +++
Sent: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.8.6.2:5060;branch=z9hG4bK134e15e1aab1679 From: "3961 tt" <sip:email@example.com>;tag=143401423~498f49ec-d955-426c-8fd4-8817ec9e8a3b-23796526 To: <sip:firstname.lastname@example.org>;tag=8C094ABC-651 Date: Mon, 05 Mar 2018 10:45:01 GMT Call-ID: email@example.com CSeq: 101 INVITE Require: 100rel----------CUBE requires reliable provisional response to its 1XX response RSeq: 6987----------Rseq for PRACK Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: <sip:firstname.lastname@example.org>;party=called;screen=no;privacy=off Contact: <sip:email@example.com:5060> Server: Cisco-SIPGateway/IOS-15.5.1.T Content-Length: 0
+++ After six attempts with no response and 12sec after the call request your ITSP ended the call +++
Received: BYE sip:7142990910;firstname.lastname@example.org:5060 SIP/2.0 Via: SIP/2.0/UDP 172.16.6.153:5060;branch=z9hG4bK5dedj62020rso5bdtpe0sdq9oftp3.1 From: <sip:email@example.com>;tag=2062967205-1520246698053 To: "3961 tt" <sip:firstname.lastname@example.org>;tag=8C094A38-25AF Call-ID: 177AFC3A-1F9911E8-A80889D2-E97120E8@172.16.6.130 CSeq: 987879411 BYE Max-Forwards: 69 Content-Length: 0
++ Suggestions +++
1. disable PRACK on your CUBE dial-peer to CUCM
dial-peer voice xx voip
voice-class sip rel1xx disable
or disable PRACK globally
voice service voip
2. Enable CUCM to process PRACK for all 1XX messages
Under: Trunk Specific Configuration
SIP Rel1XX Options : send PRACK for all 1XX messages
If it still does not work, then please do another test call and send us CUCM logs.
... View more
Looks like your provider is not complying with RFC. Here is the analysis of both traces.
++ Your Trace has multiple connection info one at session level and one at media level +++
Cisco-SIPGateway/IOS-12.x v=0 o=CiscoSystemsSIP-GW-UserAgent 4398 2360 IN IP4 10.0.1.254 s=SIP Call c=IN IP4 10.0.1.254 --------------<<< Session description >>> t=0 0 m=audio 17474 RTP/AVP 8 101 c=IN IP4 203.x.x.152--------------<< Media description >> a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 --------------------------------------------------------
++ Their trace has a single connection info at the session level ++ v=0 o=TRUNKPROVIDOR 929606340 929606340 IN IP4 188.8.131.52 s=TRUNKPROVIDOR-AST c=IN IP4 125.x.x.7 t=0 0 m=audio 14566 RTP/AVP 8 18 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv
++ To argure your corner and get them to re-write their SIP stack here is what the RFC says ++
+++ RFC 4566 +++ 5.7. Connection Data ("c=")
c=<nettype> <addrtype> <connection-address>
The "c=" field contains connection data.
A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media.
The "session description" above is the bit before any m= lines. The "media descriptions" start with an m= line. So an SDP has 1 session description section and can have multiple media descriptions. so as examples or positioning of c= lines, you can have: 1. There is one c= line at the session description Each media description uses the connection information from that top c= line. c=.... // session description m=.... // 1st media description a=..... m=.... // 2nd media description a=..... or 2. Each media description has its own c= line (There is no session description c= line): // session description (no c= line) m=.... // 1st media description c=.... a=..... m=.... // 2nd media description c=.... a=..... or 3. There is a session description c= line but the first media description has its own c= line , so the first media description's c= line overrides the session description c= line. The 2nd media description uses the c= line in the session description. c=.... // session description m=.... // 1st media description c=.... a=..... m=.... // 2nd media description a=.....
Your SIP request is correctly formatted and if they are referring to the absence of media direction in your SDP
Here is what the RFC says on that as well
++ RFC4566 ++ a=sendrecv ... If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below).
Finally on your sip profile question, I can see this working as you have configured it. In your SDP you can see the connection-info in your media description different and to what you have at the session description, this suggests to me that it is working as configured
... View more
It is easier than you think.
In my example, here is my sh inv.
NAME: "NIM subslot 0/1", DESCR: "NIM-4MFT-T1/E1 - T1/E1 Serial Module"
My NIM is on subslot 0/1. This means that each of my E1 port on that module will be numbered as follows depending on how many ports I have ( in my case it is 4)
So it will be e1 0/1/0, 0/1/1, 0/1/2 and 0/1/3
If you do a show diag, you get similar picture sh diag sub 0/1 ee SPA EEPROM data for subslot 0/1: Product Identifier (PID) : NIM-4MFT-T1/E1 Version Identifier (VID) : V04 ----- EEPROM data for slot 0 bay 1 daughter board 1 Product Identifier (PID) : PVDM4-256 Version Identifier (VID) : V02
Now you define your card type using your slot and subslot number based on the output of your sh inv. example: ( slot 0/subslot 1 and slot 0/subslot 2) card type e1 0 1 card type e1 0 2
And finally you can see all my E1 controllers controller E1 0/1/0 shutdown pri-group timeslots 1-31 ! controller E1 0/1/1 shutdown pri-group timeslots 1-31 ! controller E1 0/1/2 pri-group timeslots 1-31 ! controller E1 0/1/3 clock source line primary pri-group timeslots 1-31
In your example, you will define your config as follows
card type e1 0 1
and controller e1 0/1/0 ( you only have one port)
... View more
It all depends. If the request that is sent to CUCM has a domain name then you should add that domain name to your CFQDN. You can add multiple domain names here but ensure it is a domain that is local to you. This is because any request to this domain will never be sent out to vcsc but will be processed locally by CUCM. The OTLD ( organisational top level domain) can be used if you share a domain both internally and externally because any request that matches this domain will be checked both internally and externally. CUCM will try to route calls for this domain externally as well. You can only have one domain name here
... View more
Sure, there are a few good documents here
... View more