18 Aug
2004
18 Aug
'04
1:56 a.m.
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(a)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(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
>
>
>
--
Andrew Mee
Programmer
HealthShare
Level 3 80 Stamford Rd Indooroopilly QLD 4086 Australia
T +61 (0)7 3378 7575 F +61 (0)7 3878 9883 M 0415 9044 65 E andrew(a)healthshare.com.au W
www.healthshare.com.au
Disclaimer
The information in this e-mail is confidential and may be legally privileged. It is
intended solely for the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it, is prohibited and unlawful. Despite our
best efforts, the sender and HealthShare makes no warranties that this e-mail is free of
infection by computer viruses or other contamination.