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