Cannot transfer external incoming SIP calls on CUCM6

Unanswered Question
May 20th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.4 (7 ratings)
Loading.
htluo Wed, 05/20/2009 - 06:15
User Badges:
  • Red, 2250 points or more

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

http://htluo.blogspot.com

Nicholas Matthews Wed, 05/20/2009 - 06:23
User Badges:
  • Red, 2250 points or more

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

pverstegen Wed, 05/20/2009 - 06:48
User Badges:

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


Nicholas Matthews Wed, 05/20/2009 - 06:52
User Badges:
  • Red, 2250 points or more

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

pverstegen Wed, 05/20/2009 - 08:14
User Badges:

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

Nicholas Matthews Wed, 05/20/2009 - 10:32
User Badges:
  • Red, 2250 points or more

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

pverstegen Thu, 05/21/2009 - 00:45
User Badges:

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

Nicholas Matthews Thu, 05/21/2009 - 05:39
User Badges:
  • Red, 2250 points or more

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



pverstegen Fri, 03/01/2013 - 02:59
User Badges:

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

yahsiel2004 Fri, 03/01/2013 - 06:45
User Badges:
  • Gold, 750 points or more

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

pverstegen Sun, 03/03/2013 - 23:29
User Badges:

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

Actions

This Discussion