After much more discovery we have figured out what the issue is with the MS RTC 1.2 and SER.
This isn't so much as a bug with SER but with MS RTC 1.2, it is caused by MS RTC sending incorrect Request-URI in the headers. This only occurs in request routed mode from the callee end.
Take the example: RTC Client A SIP Server RTC Client B -----INVITE--------------> <----100 Trying----------- -----INVITE----------------> <----100 Trying------------- <----180 Ringing---------- <----180 Ringing------------ <----200 OK w/ INVITE----- <----200 OK w/ INVITE------- -----ACK-----------------> -----ACK------------------->
All is fine at this point, however now lets send a message from A to B: RTC Client A SIP Server RTC Client B ----MESSAGE b@server----> ----MESSAGE b@server----> <----200 OK ------------- <----200 OK --------------
All is still fine, However if we send a message back from B to A: RTC Client A SIP Server RTC Client B <----MESSAGE b@server---- -----MESSAGE b@server----> <----481 Call Leg/T DNE--- This is obvious because the SER server sees this message as needing to go back to B when it should be forwarded to A as per "8.1.1.1 Request-URI" of the rfc (as far as my understanding on this). This issue occurs with BYE commands and possibly other types of commands.
I might add the To: and From: header fields are correct.
Solution to this problem could (or is there an existing way) a module/control could be created that checks if the To: field doesn't equal the request-uri that the request-uri be changed to the information in the To: field?
Yes I agree that while this is a MS RTC problem, I figure this is going to be a better/quicker short term solution. I have not tested if this problem exists with other SIP servers.
I can send some ngrep logs if anyone likes?