uc320w autoattandent not working with SIP trunk

[felipeg007]

I have a new install Firmware 2.1.1  with a sip trunk and 4 FXO lines.

the autoattandent works when calling the system from the the POTS lines but not the sip trunk.

i have double and triple checked all setting and here is what i have tried to rule out

a sip trunk issue.

If i configure a call route and route the call to a phone or mailbox it works great.

if i send it to autoattendant it rings 3 times and drops the call.

if i route all calls to anything other then AA it works no dropped calls

i have tried disabling autoattendant and recreating the menu prompts.

i have removed phones and users.  still no luck. a hard reset has not been tried because the sytem is remote.

i tried renaming the default route thinking the name on the sip trunk and FXO is the same and may conflict. still no luried ck.

i have not tried deleting the sip trunk completely and recreating it.

any help or ideals would really help.

is my AA some how corrupt?

Thank you for your time,

Felipe

[ADAM CRISP]

Hello.

We have this problem on all our SIP trunks (we are a SIP Service provider).

This problem happens (on our network) because the uc320 states a particular codec should be used ( in it's 200 OK SIP response) despite the initial offer from our network not containing this codec.

We have a PMF from Cisco which fixes this for us, and I'll provide here, but I don't have the "undo" version of the PMF.

We can ask for one if you try to add but it doesn't help

http://dl.dropbox.com/u/73561/DisableNSEsdpOption.pmf

If you have a good way of capturing your SIP trace, I'll go through this with you to see if you're hitting the same problem.

Adam

[felipeg007]

sip call

[felipeg007]

why does it only impact  calls to AA and not call to voice mail.

[ADAM CRISP]

Sorry - Is this now working ?

[felipeg007]

it still drops call after user picks up

[felipeg007]

we just took a full TCP Trace instead of just a SIP trace.

Provider sends the invite for the inbound call.  They requested to use RTP port 49954 (order 1. 729 2. 711)  We sent a 200Ok and said audio to be on port 10560 (order 1. 711 2. 729).  However when we start sending RTP traffic we are sending from 16456 (not 10560) which is why we think the call drops.

so at first the uc320 stated it would send on 10560 but then it switched to 16456.

Message was edited by: felipe garcia

[ADAM CRISP]

The SIP dialogue looks OK, no evidence of the problem we see, which is good. The Sip trace you posted - was this captured from your firewall, the public side of 205.226.32.5 ? If it is, what's 192.168.10.5? the SP won't know how to route meadia to here,,,,

Please tell us where you're capturing the trace from. If the trace is from  the UC320 - please can you re-capture, but this time for a working call in to a handset. it would be interesting to see if there is any difference in SDP.

thanks

[felipeg007]

above is my uc320 sip trunk.

attachement,  my sip provider captured this when he tried making a phone call to the uc320 ,

yes it sits behind a firewall.(grey-field install)

but i have a direct nat. and i have NAT checked on the uc320 with the public address in the settings.

the phones sit behind uc320 on the vlan 100 (10.1.1.1).

the WAN port sits behind the firewall on another private network.

[ADAM CRISP]

I've had a look at this trace and it looks OK at a first glance.

What I would say is that the Service Provider closes the calls VERY quickly (less than 1/2 second) after receiving the 200OK from the UC320. I think you should ask them why they hung up the call.

I'm wondering whether there's something else happening within their network that we are not aware of.

Also, please can you clarify whether the trace you posted was for a call being routed to the AA. It would be good to compare a working call direct to a handset.

thanks

[ADAM CRISP · Accepted solution]

Hello.

I've had another look at this trace in the light of day, and the only thing that looks "fishy" is the Packet Time, request of 30ms from the UC320 and 20ms from the Service provider.

This shouldn't matter. The UC320 is sending 20ms packets to the SP as requested, but given that the SP sends no media to the UC320 and hangs up the calls pretty quickly, I think the problem is with the Service Provider. Maybe they're recording calls for you and don't support P30 - it doesn't help that their BYE doesn't give a reason.

I suggest raising a Trouble Ticket with the SP and ask them to take a look at your trace and their Acme packet logs. (and beyond) also take the time to compare a working incoming call straight to a handset. You might also want to ask Cisco if there's a way of setting the UC320's preferred Ttime to 20ms as a work around.

Adam

[Alberto Montilla]

Hola Felipe;

I would tend to agree with Adam, looks like a packetization issue (just by looking at how soon the server closes the connection).

Who is the Service Provider? Just want to make sure we provide proper solution. Let me know so that we can create the PMF for this one.

Regards
Alberto

[felipeg007]

I have some new info.

First we moved the cisco out from behind the firewall and gave it a public IP.

Same results.

The provider is Mettel.

and they are seeing the following.

Invite RTP Port 49945 (MetTel's Port)  

200 OK w/SDP RTP Port 10560 (UC's Port) – UC says they will send on port 10560 but actually send from port 16456

They agree with adam and have asked to increase the PTIME to 20 on the SIP packets.

Can this be done on the cisco side?

[ADAM CRISP]

Chaps,

Let me know what happens with this one,

Adam

[felipeg007]

We finally got this working. The cisco tech first tested the fix by applying it manually

under advanced configuration.   *Consumers do not have access.

Changing the the RDP packet size(PTIME) from .03 to ->  .02.

Once this worked she applied a PMF file that does the same thing.

The PMF is called cox.pmf. I have attached both file incase someone needs them.