About Ayodeji Okanlawon

Ayodeji Okanlawon · ‎01-16-2019

Hi, With one-way audio the key things to verify is that there is connectivity between the media path used for the rtp streams. From your ITSP to the CUBE interface facing the ITSP, you need to check the IP address that CUBE is asking the ITSP to send media to. Unfortunately because you have hidden this, its difficult for me to tell. Also if you have multiple interfaces on your CUBE, then you need to ensure that you have configured your sip bind statements correctly so that signalling and media originates from the right interface.

Ayodeji Okanlawon · ‎01-16-2019

Mark, The flow for call hold/transfer with CUCM is this 1. CUCM sends re-invite with inactive SDP to indicate a break in media path. 2. CUCM sends a DO to insert MOH or to resume media stream NB: CUCM expects a send-recv offer with SDP in responde to the DO. If CUCM gets an inactive offer SDP in the 200 OK, the media path remains inactive state and the call drops So when you say you do not see the re-invite with inactive SDP then something has gone amiss. We need to look at the logs to see why. CUCM must indicate a break in media path using a=inactive

Ayodeji Okanlawon · ‎01-10-2019

Can you send or attach your ccsip all debug here?

Ayodeji Okanlawon · ‎01-10-2019

Why do you need to do this? If you give us a clearer picture we might be able to provide a more accurate response

Ayodeji Okanlawon · ‎12-04-2018

If cucm is sending 200 ok and the calling phone dies not get it, then look at the IP address the 200 is sent to. If these are in same subnet, reboot your cucm and vm.

Ayodeji Okanlawon · ‎12-04-2018

Hey Alex, The first part is straight forward. The via header has preference over the from header. This is a well established fact. The document also states this is based on the order of dialpeer selection for incoming URI matching. On the second, I can't comment but will go with your real life experience. IOS version may also play a part here...

Ayodeji Okanlawon · ‎11-12-2018

Hi, The reason you are not getting any response to the 200 OK message is that the contact header in 200 OK is not reachable from the ITSP. Here is the INVITE from ITSP Received: INVITE sip:05428862999@10.36.0.170:5060 SIP/2.0 The INVITE was sent to 10.36.0.170 And here is the 200 OK that CUBE is sending: Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.36.0.169:5060;branch=z9hG4bK0cBd6228d56d5f75c5f From: <sip:02155777509@10.36.0.169>;tag=gK0c73d967 --- --- Contact: <sip:05428862999@10.8.30.254:5060> ++ as you can see CUBE is asking ITSP to send ACK to 10.8.30.254 ++ This is most likely happening because you have not configured the correct SIP bind statements on your dial-peer You can refer to this link to understand how to correctly setup this on dial-peers https://community.cisco.com/t5/collaboration-voice-and-video/cube-sip-media-and-signalling-binding-to-an-interface/ba-p/3107153/page/5

Ayodeji Okanlawon · ‎10-29-2018

This picture is not clear. Why do you need the prefix. If you are routing based on called number, then all you need is dial-peers that match the called number. I am guessing there is more to it. So please elaborate on what you are trying to do.

Ayodeji Okanlawon · ‎10-28-2018

have you tried.. sh dialplan number +9999+ 4525446346

Ayodeji Okanlawon · ‎10-16-2018

The XML default is not for specific phone model. Its for all phones..Attached here is the file Remove the .txt extension

Ayodeji Okanlawon · ‎10-16-2018

Diego, I know @Jaime Valencia knows his stuff but hey check this: I have been a VIP for 6 years now, I also have CCIE in collaboration I have also written many useful documents for this forum I am just saying I know my stuff too :) Here is how to use calling party transformation: Create a calling party transformation pattern: Eg if you all extensions beginning with 2XXX to have a CLID of 800.555.1212 Do this: pattern: 2XXXX Partition: any_pt you want to use eg transform_pt Calling party xform mask: 8005551212 pattern: 3XXXX Partition: any_pt you want to use eg transform_pt Calling party xform mask: 8005551213 Create a CSS: call it anything you want: eg Transform_CSS assign the partition of the pattern above to it. Then ensure that on the phone this box is ticked: Use Device Pool Calling Party Transformation CSS Then on the Device Pool, under: Device Mobility Related informartion>Calling Party Transformation CSS select the calling party xform CSS above That should do it

Ayodeji Okanlawon · ‎10-13-2018

I experienced this a while back and it was a bug. i will try and dig out tgr details for you

Ayodeji Okanlawon · ‎10-12-2018

Please enable diagnostics loggin on both c and e of the failing pair. Reproduce the issue. Stop the logs once you have finished reproducing it and attach it here. Include calling and called number Also collect cucm logs for the same call and attach here as well

Ayodeji Okanlawon · ‎10-12-2018

You can use calling party transformation pattern and apply it to the device pools

Ayodeji Okanlawon · ‎10-02-2018

Okay this suggests that your CCME is using the contact header for CLI display rather than the remote-party-id Can you try this please.. conf t sip-ua remote-party-id This should be enabled by default..but I am not sure why the gateway is behaving this way..But try the command above and check again

Date Registered	‎09-10-2007 02:20 AM
Date Last Visited	‎01-18-2019 04:06 AM
Total Messages Posted	7,644
Total Helpful Votes Received	10734

Re: SIP One way with cube need help

Re: Losing call when placed on hold

Re: sip messages not shown on Translato...

Re: Re-Download Cisco CUCM ITL file to ...

Re: Call setup wont complete

Re: SIP inbound dial peer selection

Re: Inbound call using SIP disconnected...

Re: SIP dialpeers, "show dialplan numbe...

Re: SIP dialpeers, "show dialplan numbe...

Re: UC Phone CP 8831: Need XMLDefault.c...

Re: options for setting outgoing caller...

Re: CP-8861 Stuck in VPN mode

Re: Calls through Expressway Cluster fa...

Re: options for setting outgoing caller...

Re: cisco CME SIP trunk with Avaya call...