05-20-2009 06:08 AM - edited 03-18-2019 11:04 PM
Hi, I'm using a CUBE to forward incoming SIP calls to CUCM6. Everything works fine accept transfering external SIP calls to an internal directory. Transfering an internal call to an internal destination works also very well. Seems signalling works fine (ringing) but media is not transfered. Does anyone have an idea what's wrong?
Regards, Peter
05-20-2009 06:15 AM
If only the media not transferred, I would guess network (routing) issue.
You'd better do packet capture on the CUBE and on the phone. So you can see if the CUBE sent out the RTP packets and if the phone received it.
Michael
05-20-2009 06:23 AM
What type of CUBE is this? SIP-H323, SIP-SIP?
What does your voice service voip configuration look like?
What IOS version are you on with CUBE?
Do you have MTP Required checked on your H323 gateway / SIP trunk configuration?
-nick
05-20-2009 06:48 AM
What type of CUBE is this? SIP-SIP
What does your voice service voip configuration look like?
voice service voip
allow-connections sip to sip
no supplementary-service sip moved-temporarily
fax protocol cisco
What IOS version are you on with CUBE?
flash:c2800nm-ipvoice_ivs-mz.124-24.T.bin
Do you have MTP Required checked on your SIP trunk configuration? NO
05-20-2009 06:52 AM
A few commands to try:
voice service voip
no supplement sip moved
sip
midcall-signaling passthru
As well, you may also have a different outcome if you add:
voice service voip
sip
early-offer forced
-nick
05-20-2009 08:14 AM
Hi Nick,
With "midcall-signaling passthru" calling in with my cell phone works fine, transfering works fine but there is only one-way-audio from inside to cell phone. So the inside party doesn't here anything.
This is the same with and without
"early-offer forced".
Any suggestion?
Peter
05-20-2009 10:32 AM
Hi Peter,
It's really hard to say. I would check the outgoing SDPs you send after the transfer to make sure you're sending a reachable IP address and that it is a=sendrcv. You may also want to try throwing an MTP on the SIP trunk just to see if it helps.
Other than that, you can use 'show call active voice brief' to see if packets are coming in.
traffic-export is also a cool feature that will let you get a packet capture and you can look at the capture to see if the audio is coming in/out. Instructions:
!create profile
ip traffic-export profile TAC mode capture
bidirectional
exit
!apply to an interface
interface fa0/0
ip traffic-export apply TAC [size
If you're worried about the max size you can put the max size in. The default is 5 MB.
Then you can use these exec (enable) level commands:
Router#traffic-export interface fa0/0 clear
Router#traffic-export interface fa0/0 start
Router#traffic-export interface fa0/0 stop
Router#traffic-export interface fa0/0 copy ftp://x.x.x.x/sniffer.pcap
hth,
nick
05-21-2009 12:45 AM
Hi Nick,
Thanks for your excellent support.
The cube seems to do well. If I pick up my cell phone on a third-party SIP device, transfer to a skinny device works fine. But when picked up on a skinny phone, transfering results in one-way audio. All devices are connected to CUCM6.
Regards, Peter
05-21-2009 05:39 AM
Hi Peter,
I know CUCM is going to treat a SIP phone differently than a SCCP phone. The way they handle media is quite a bit different due to the SIP/SCCP protocols.
Not much else you can do other than what I've already listed:
-Try it with MTP. A lot of transfer scenarios can be fixed with this, as this was one of their original functions.
-Get the packet capture off CUBE and inspect the RTP streams
-Check out the SDPs after/during the transfer and make sure the IP addresses are right and you're not getting a=recvonly or a=sendonly as the last SDP.
You can check the webpage of your phone to see where it's sending packets. Then, you can do 'show voip rtp connections' on the router to get this information.
You may want to check out this document I wrote up using 'show call active voice brief'
-nick
03-01-2013 02:59 AM
Hi Nick,
I would like your assistance please.
When making SIP call's after some time the answering or calling party get's one way audio.
My SIP provider started some debugging and is telling me that mij CUBE is the cause of problems.
This is what they tell me: During the call the CUBE is doing connection control which causes the call to be reestablished again and again. The reason for this would likely be this setting: session;handling=required.
How can I change this setting in IOS?
c2800nm-ipvoice_ivs-mz.124-24.T.bin
Best regards,
Peter
03-01-2013 06:45 AM
Peter,
This is a routing issue not a CUBE issue. CUBEs purpose is to terminate and re-create calls that go through it to provide address hiding. So unless your SIP Carrier allows you to show your internal address and your Company allows for you to show their internal network than you can do "Media Flow Around". Obviously for many reasons this is not recommended and it's only used between branch offices or sites2sites since there is no need to hide internal addresses. I would get with your network guys and verify the routing configuration.
Regards,
Yosh
03-03-2013 11:29 PM
Hi Yosh,
This is definitely not a routing issue. Everything works fine, only during calls there are occasionaly some one-way audio issues. My SIP provider started some debugging and is telling me that mij CUBE is the cause of problems.
This is what they tell me: During the call the CUBE is doing connection control which causes the call to be reestablished again and again. The reason for this would likely be this setting: session;handling=required.
How can I change this setting in IOS?
c2800nm-ipvoice_ivs-mz.124-24.T.bin
Best regards,
Peter
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: