 | 1 | initial version |
Here my feed back to the cause and solution of the problem.
One thing I noticed in the pcap is that the provider does not send a ptime parameter in it's SDP packet. Only a maxptime parameter. This was a good find! Also our support for the Alcatel PBX found this behaviour. This was the root cause of the problem!
None of the end points, neither or Alcatel PBX nor the other phone partner, did set a ptime parameter when establishing the SIP connection. Both sides did only specify a maxptime. Sometimes the other end of the call did not even specify a maxptime. This made the Alcatel PBX "think" it was free to choose and change the ptime as it saw fit.
The solution was to configure the Alcatel PBX for a fix ptime of 20ms
The answer of our VOIP provider about this was, that SIP/SPD is transparent. The part of the provider is only call transfer. The ptime is negotiated between the end points of the call and is not set by the provider.
| | 2 | No.2 Revision |
Here my feed back to the cause and solution of the problem.
One thing I noticed in the pcap is that the provider does not send a ptime parameter in it's SDP packet. Only a maxptime
parameter.parameter.
This was a good find! Also our support for the Alcatel PBX found this behaviour. This was the root cause of the problem!
None of the end points, neither or Alcatel PBX nor the other phone partner, did set a ptime parameter when establishing the SIP connection. Both sides did only specify a maxptime. Sometimes the other end of the call did not even specify a maxptime. This made the Alcatel PBX "think" it was free to choose and change the ptime as it saw fit.
The solution was to configure the Alcatel PBX for a fix ptime of 20ms
The answer of our VOIP provider about this was, that SIP/SPD is transparent. The part of the provider is only call transfer. The ptime is negotiated between the end points of the call and is not set by the provider.
