> -----Original Message-----
> From: Brett Tate [mailto:[email protected]]
> Sent: Friday, 25 January 2013 6:23 AM
> The UAS cannot assume that requests will not be retransmitted over
reliable transports (such as TCP). RFC 2543 indicated to use the same retry
rules when sending over reliable and non reliable. RFC 3261 adjusted the
retry rules; however I don't think that it adjusted how the UAS would behave
upon receiving the retry.
> The issue with RFC 3261 was that it indicate 0 as the default Timer J
value for TCP/SCTP. You can fix the issue by increasing Timer J to be the
same as it would be for UDP.
I would also be of the opinion that a UAS should deal with retransmits the
same way irrespective of the transport type. Unfortunately in this case the
softphone developer, Counterpath, seem to have interpreted things
differently...
"... The server is sending the message twice, and you are receiving it
twice, because the client that is sending the message is using a UDP
connection which is not as reliable as TCP.
It seems that the Server is not receiving a response fast enough, so it will
send the message again.
Regardless, the issue does not lie with Bria but with the network.
Customer Support
CounterPath Corporation"
And as far as I can tell there is nothing definitive in RFC3261 which
clearly states how to deal with this situation.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
