I haven't looked into UDP yet as I have a TCP requirement..... however I will look into it further.. Although I'm wondering does UDP use record_route? Hmmmm.... I found that if the mode was set to loose routing (TCP) the problem didn't occur because the UA sent the messages directly to each other, is this what you see? Does the UDP set the request-uri properly? you should be able to see this in your ngrep/ethereal.
How good is your C programming :) a 'correcting module' under 'rr.so' would be my recommendation...
Andrew
Jonathan wrote:
Hello Andrew,
It seems im also being troubled by the problem you have perfectly put into words unlike the one in my email. ^_^
I just want to ask though, because when i use UDP as the protocol in my rtc profile, this problem does not occur and communication flow between user A and B goes smoothly.
Do you think there is an explanation behind that? Why would SER/RTCDLL combination work when it's under UDP and not when using TCP?
I really have no idea, just observations.
Any comments and/or ideas regarding this issue would greatly help.
Thanks alot in advance.
- Jonathan -
On Wed, 18 Aug 2004 09:46:05 +1000, Andrew Mee andrew@healthshare.net.au wrote:
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?
-- Andrew Mee
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers