Hello all,
I've got a very peculiar issue with a CUCM migration that we attempted to do today. We installed some new 7821 phones, replacing some 7911 phones and migrated them from CM7 over to our CM11.5 cluster. All went well and this is the 25th site that we've migrated in this way, the other 24 without any glitches. However, we hit a big issue, not with calls being allowed in, but with calls not being allowed out.
The DNA shows that calls were allowed and showed the correct path that the calls should be taking. I had a look through the trace errors to see where the issue may lie and got this:
2019/04/03 15:05:50.332|CC|SETUP|41425364|41425370|xxxxx900160|9xxxxx998476|9xxxxx998476
2019/04/03 15:05:50.335|CC|OFFERED|41425364|41425370|xxxxx900160|9xxxxx998476|9xxxxx998476|SEPB0907EFxxxxx|SonusSBC-1
The CUCM sends an INVITE to SonusSBC-1
2019/04/03 15:05:50.336|SIPT|41425370|UDP|OUT|x.x.102.23|5060|SonusSBC-1|x.x.102.68|5060|2,100,14,17659378.38^x.x.4.6^*|1398699219|94a57880-ca41bdbe-1858f02-17669c0a@x.x.102.23|INVITE
The SBC-1 sends back a 400 Bad Request
2019/04/03 15:05:50.338|SIPT|41425370|UDP|IN|x.x.102.23|5060|SonusSBC-1|x.x.102.68|5060|2,100,10,1.24154534^x.x.102.68^*|1398699220|94a57880-ca41bdbe-1858f02-17669c0a@x.x.102.23|400 Bad Request
CUCM Acknowledges
2019/04/03 15:05:50.338|SIPT|41425370|UDP|OUT|x.x.102.23|5060|SonusSBC-1|x.x.102.68|5060|2,100,10,1.24154534^x.x.102.68^*|1398699221|94a57880-ca41bdbe-1858f02-17669c0a@x.x.102.23|ACK
Then CUCM tries SonusSBC-2 (he's next in the Route List)
2019/04/03 15:05:50.341|SIPT|41425370|UDP|OUT|x.x.102.23|5060|SonusSBC-2|x.x.102.84|5060|2,100,10,1.24154534^x.x.102.68^*|1398699222|94a57880-ca41bdbe-1858f03-17669c0a@x.x.102.23|INVITE
He says no too with a Bad Request
2019/04/03 15:05:50.345|SIPT|41425370|UDP|IN|x.x.102.23|5060|SonusSBC-2|x.x.102.84|5060|2,100,10,1.24154535^x.x.102.84^*|1398699223|94a57880-ca41bdbe-1858f03-17669c0a@x.x.102.23|400 Bad Request
CUCM Acknowledges
2019/04/03 15:05:50.345|SIPT|41425370|UDP|OUT|x.x.102.23|5060|SonusSBC-2|x.x.102.84|5060|2,100,10,1.24154535^x.x.102.84^*|1398699224|94a57880-ca41bdbe-1858f03-17669c0a@x.x.102.23|ACK
CUCM tells the phone he’s had no joy
2019/04/03 15:05:50.348|SIPL|41425364|TCP|OUT|x.x.102.23|5060|SEPB0907EFFCEDB|x.x.4.6|51044|2,100,10,1.24154535^x.x.102.84^*|1398699226|b0907eff-cedb0005-139f3967-7fae3796@x.x.4.6|400 Bad Request
Phone Acknowledges
2019/04/03 15:05:50.452|SIPL|41425364|TCP|IN|x.x.102.23|5060|SEPB0907EFxxxxx|x.x.4.6|51044|2,100,14,17659378.41^x.x.4.6^*|1398699244|b0907eff-cedb0005-139f3967-7fae3796@x.x.4.6|ACK
Status is Reject
2019/04/03 15:05:50.453|CC|REJECT|41425364|41425370|xxxxx900160|9xxxxx998476|9xxxxx998476|16777257
Oddly on the site, there are 16 phones, 15 of them get the same result when calling out and 1 works just fine. All config is identical.
Upon some further investigation as to the cause of the SBC's sending a Bad Request, I found the following:-
The SBC (x.x.102.68) is sending a Bad Request to the CUCM (x.x.102.23) due to a SIP syntax error!
I tried changing the CUCM server the phones were attached to (there are 4 subscribers to pick from) and that didn't make a difference. I also went through the configuration and nothing is different to any other sites that we have on either the phones, their device pools or the route patterns. I also moved the non-working phones into a device pool of a working site, CSS and all, and that didn't working either.
I then got a packet capture and looked through the packet make-up of a good call (from a different site, same model phone, same configuration) and a Bad Request call from this site and they are, again, identical.
Can anybody shed some light on this? What is the CUCM server sending to the SBC that it causing it to claim there is a syntax error? And furthermore, what could the phone be sending to the CUCM server that would make it send invalid syntax? AND (last, but not least), why does one of the phones on the site that is configured identically work?!?
Any guidance will be most appreciated as I've ran out of ideas of where to look.
Best, Leigh
Hi there,
Thanks for responding, it's much appreciated.
Here is a shot of the packet capture of the INVITE that gets the Bad Request back:-
The INVITE is sent when I try to dial an external number.
Best, Leigh
