5 Mar
2003
5 Mar
'03
4:07 a.m.
Greg,
thanks for updating me. I maintain ser is not guilty, snom is.
Replies bellow.
On Tue, 4 Mar 2003, Greg Fausak wrote:
[...]
INVITE -> *
401 Unauthorized <- *
ACK -> *
INVITE (with credentials) -> *
100 Trying <- *
183 Ringing <-
PRACK -> *
200 OK <- * (this is OK for the PRACK)
200 OK <-
This is where things get off track, the SNOM phone wants to send the
ACK to the GATEWAY instead of the PROXY. All of the messages
above that have an * means no record-route is present in the message.
What SNOM is saying is that the *first* OK from the PRACK sets up
Who to send the message back to....that doesn't make sense to me. The
*second* OK from the INVITE is that SNOM is responding to, so why don't
they
use the record-route that is in that message.
The long winded answer is yes, they think SER should be providing a
'Record-route' in the first OK.
Record-route is mirrored in replies from requests by phones, not by proxy
servers. If it is missing in replies to record-routed requests, it is
phone's fault.
The proper behaviour is imho as follows:
- INVITE is record-routed by proxy; 18x replies must mirror record-routes
(if they don't, it's phone's UAS bug)
- subsequent transactions must use route set learned from the INVITE
transaction; that means, PRACK should set Routes, and so should later
on the ACK too; (if that does not happen, it's phone's UAC bug)
So I think the snom-phone bugs encountered here are:
- route learned from INVITE 18x is not set for PRACK and ACK
- record-route is not mirrored in replies to PRACK
-Jiri