Hold problem with Snom300

[tron]

Hi,
I've been asked to help diagnosing a problem with a SNOM300 not being able to
make supervised (consultation) transfers with a Quadro.
Turns out, the problem is that hold is not working. When you press the line button,
phone behaves like the line is on hold (display hold + line blinking) but the Quadro
does not start MOH and clears the call in 10 seconds.

I have compared the SIP messages from behaviour to the (working) hold procedure
of a SNOM370 on the same Quadro, and I can not find what is different.

The problem seems to follow the phone model, 2 SNOM300 behave the same.
What puzles me is that the hold re-INVITE seems to progress fine.
The line is provisioned with 2 line appearances. I have network traces of a working and
a non working hold, if it helps.

TIA,
-Carlos

[Ashot]

Hi Carlos,

Please check which FW version is running on snom300. If it is 8.x.x then seems it is a known issue described as 16734 in the release notes. If it is the case use the following workaround: configure the SRTP settings for snom300 extension to "make and accept only unsecure calls"

Thanks
Ashot

[tron]

I'll try that (or the closest thing that I found that is setting SAVP to off).
I searched snom wiki and could not found any 16734 issue. But alas,
the phones are running 8.4.31.
Thanks!
-Carlos

[tron]

Nope, that did not do the trick
-Carlos

[KSComs]

Try Downgrading the SNOMs to 7.1.39 and see if it is firmware related - fortunately for you it is only 2 x handsets.

Possibly it is a problem with firmware missmatch.

Another thing you could do is look at the SNOM wiki for what makes the SNOMS happiest with the Quadro and see if that gets you closer.

Just some thoughts...

Kevin

[tron]

OK, will try the downgrade to 7.1.39. But would be happier if I could understand what is that makes the Quadro clear the call.

BTW, I was looking for the 16734 in teh snom firmware release notes, turns out it is
a Quadro release note, and the configuration suggested is for the Quadro.
But... current configuration was already set for "make and accept only unsecured calls".

-Carlos

[tron]

Did not do the trick, same thing, Quadro clears the call 10 seconds after the hold

-Carlos

[ArmenN]

Tron, it will be good to have systemlogs of Quadro or at least network capture to answer more exactly what is happen. I believe, there is no any trick.

From discussed above I can guess you are about Snom's bugfix described in Release Notes of latest Release Candidate ver. 8.4.32:

SIP
2. SCPP-2793: Fixed - Missing crypto key to sendonly sdp (hold), but only if user_moh is empty.

In other words, the Hold procedure on Snom phones (with FW 8.x.x) with Quadro fails if in SDP present any SAVP (missing crypto in SAVP). After ~10 second call is dropped, since timeout occurs.

Please, do the ONE of following points and check Hold/Consultative Xfer functionality:

1. Upgrade Snom300 from 7.1.39 to 7.3.27 which is recommended one by Epygi for working with Quadros. Version 7.3.27 does not have this bug.

2. Turn off "Enable firmware version control" from "Line Settings" page on Quadro and upgrade FW version of Snom300 to 8.4.32 ( http://downloads.snom.net/tmp/snom30...-SIP-RC8-f.bin, not public yet).


P.S. After changing "SRTP settings" or anything related to Phone don't forget reboot it to update configuration.

[tron]

ArmenN,
thanks for taking the time to post. I have some additional data that can be helpful,
and some questions regarding your assumed problem. In the meantime I will try the fix
nevertheless.

Data:
-internal and FXO parties are put on hold w/o trouble.
-problem only happens when remote party is through ITSP.
(but note that a neighbour snom370 has no issue with putting on hold the same
ITSP party).

Question:
All proposed fixes so far seem to point SRTP as the problematic component, so to say.
But I have disabled the phone and the quadro as far as I know about trying SRTP.
There are no SAVP lines in the phone-quadro SDP conversation.
Also, I do not see where is the timeout ocurring, since the hold reINVITE is being
OK/ACKed. The quadro is clearing afterwards, so it may be some difference in the
treatment to the ITSP. I have not done an ITSP capture though.

-Carlos

[tron]

Well, still no go. 7.3.37 does not fix this.
I also tried putting RTP proxy on the dialing rule to the ITSP, on the hope that
that would make for an MTP (cisco parlance ?), i.e., a signaling reference point
that isolates from the external (ITSP) signaling. No good either.
I guess I'll have to dig in the external connection.
BTW, is there any way to ask the SNOM300 to hold the line via web ?
That would make my life easier...

-Carlos