UCM6510 doesn't send SIP 200 OK, what happen


#21

I requested capture from SIP provider side, and they also didn’t receive the 200 OK


#22

Now i am thinking it could be a bug. I config 6 peer SIP trunks to Provider; 1 audio conference; 11 IVR; 3 Ring group; 6 Call queue; 2 pickup group. Is it to much ?
Next step i am going to restore UCM to the configuration before we got this issue (at that time there was almost no incoming call). And then i manual update new configuration again.
That is the final thing i can do, hic …


#23

When I was asking about a capture from both interfaces I was referring to “your” interfaces being that you are running in dual mode. I already could see that the provider was not getting the 200OK.

The NAT settings may need some clarification. You are running in dual mode, which is again, why I am asking to see a pcap from the UCM that shows both sides (LAN1 & LAN2) at the same time. We need to eliminate all possibilities. I would not revert to an earlier firmware just yet.


#24

I am guessing that the OPTIONS request is the heartbeat/qualify between the two UCMs. An IVR, on its own has nothing to do with OPTIONS. Here is a trace of what an IVR normally looks like:

The call comes in from the SIP provider. The UCM immediately answers the call with a 200OK and the call is established with the response of the provider’s ACK whereupon the audio stream is begun which is the IVR announcement. I then make a selection (highlighted in Yellow) of 1, which then causes the UCM to transfer (INVITE) the call to a remote phone. The call is answered and then when complete, the call is ended.

buratino01’s call never received the 200OK; so no audio was heard and no selection could be made. The UCM apparently saw the call and logged it as a missed call in the CDR. The question is, what happened? As we only see the messaging between the provider and the UCM, this opens the question of whether or not the call tried to go to something else either within the UCM itself or to the other interface which is not shown in the traces provided.

It would also be good to see the inbound rule screenshot for the particular DID in question in addition to a capture of LAN1 & LAN2.


#25

Earlier log show that this call was send to phone not keep in IVR.
Phone do not respond anything after 100, so it was not UCM fault at all.
I asked to upgrade GXP16xx from 4.82.


#26

Marcin, not sure the same issue.

The called was cancelled in .06 seconds of the trying. The poster was using this Pcap to illustrate an issue with outbound calling, not from the UCM. However, what I find strange is that:


Look at the number of INVITEs where the call setup shows no final response.
The ones with 2 packets only show the INVITE and a TRYING, nothing else. They are on different firmware than the 4.82. It kind of looks like a ring group that loops back or to another group with the same extensions. What the origination is, IVR or direct to RG via DID is unknown.


#27

Please look at 2 Failed call (remember, on CDR they are Failed call, not missed call)

Capture for LAN1:
https://drive.google.com/open?id=1xuBFTx21frYbDtTA9RNHEk1SA_kXbH01
Capture for LAN2:
https://drive.google.com/open?id=1SzQ1YARPFrMjjZ8Xsd6odSnURlIl36-J


#28

The fact that the UCM sees and records the call is what is important.

Can you advise as to what call I should be looking for in the pcap files?
It does help when seeing numerous entries.

What does the CDR show if you click on the “+”?


#29

Hi
Now we are using a little bit complex call routing, can you help me to check is there any problem:

From 6h to 22h:


#30

And from 22h to 6h


#31

Here guy, no IVR connected


#32

They appear to be routing to an external number…call to.

On your drawing, call Qs or ring groups and regardless, what happens if all agents are busy or do not answer…is there a default destination?


#33

I have no default destination.
For queue 9101 and 9106 i set up max wai time is 0 (no limot).
For queue 8601 i set max wait time is 20s, if no answer it fw to queue 9101.
Is it ok ?


#34

It is if that is the way you like it. I have found that an unlimited wait time is somewhat self-defeating.
The issue to me is that people will only wait for so long and then they will hang up. While you do have some failover activity, the number of agents will likely vary from day-to-day as will the volume of calls.

Also, it is an unknown as to how many calls you may allow into a Q.


#35

Ok i ll try set to 60s then hang up


#36

60s is perhaps too short and hanging up is not the most friendly thing. Why not a VM destination or a virtual Q where the caller can have the system call them back without loosing their place in line?


#37

Tks i ll consider your sugestion.
But every calls should reach the first IVR, no matter what anything after that


#38

@lpneblett
Yes different, you right.

@buratino01
Can you catch syslog on UCM ?
channel and pjsip (all level).
You need download it after such bad call as with so much calls it can be overwrite fast.

This will tell us what exactly UCM do with call.
Also can you check inbound routes ? maybe there is something wrong set there ?


#39

I show you inbound routes configuration, In office time i use one IVR, and out of office time, it is another IVR

Syslog file: (from 11h-12h 9 July, and 14h to 15h30, there are about totally about 100 failed calls)
But tomorrow i ll update you syslog with “channel” and “pjsip”
syslog.zip (2.0 MB)


#40

Hi Marcin
Help me to see the syslog for this failed call from 0964150186 to 02439743556
Syslog file
syslog2.zip (2.6 MB)