[Serusers] MSRTC DLL Bug with SER

[Andrew Mee]

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 at 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 at server---->    ----MESSAGE b at 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 at server----
>>                             -----MESSAGE b at 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 at 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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: andrew.vcf
Type: text/x-vcard
Size: 889 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20040818/7212bb40/attachment.vcf>