On Tue, Oct 31, 2017 at 10:38:00PM -0400, Dale R. Worley wrote:
> As others have said, the problem must be solved by the UAs, not the
> proxy. Indeed, what with possible network delays and re-sending of
> lost packets, there's no way to guarantee end-to-end sequencing of
> messages. Even with TC
Alex Balashov writes:
> 5. UA B sends end-to-end ACK for reinvite #1 and almost
>simultaneously sends reinvite #2. The temporal delta is
>between reinvite #2 and ACK for reinvite #1 on the wire
>is 3 ms.
>
> The issue is that the concurrency characteristics of proxy P are such
> that i
Paul,
I'm not a SIP standards expert by any stretch, but yours is the interpretation
I tend to favour and which sits best with me.
Since in-dialog requests are originated by the dialog parties, timing issues
belong with them, not with intermediate proxies IMHO.
On October 31, 2017 10:50:45 AM
On 10/31/17 8:44 AM, Liviu Chircu wrote:
Hi Alex,
IMO, building logic into the proxy which encourages/mends the proper
sequencing of UDP messages does nothing more than to hide the underlying
problem, i.e. "UDP does not guarantee message sequencing in the first
place" *. There is also a subtl
Hi Alex,
IMO, building logic into the proxy which encourages/mends the proper
sequencing of UDP messages does nothing more than to hide the underlying
problem, i.e. "UDP does not guarantee message sequencing in the first
place" *. There is also a subtle point to be made here: your proxy's
loo
