On Wed, Feb 10, 2016 at 8:20 AM, Alex Balashov
wrote:
> Seems one can't win. There's got to be a reason this option came about.
> However, it's been around for a long time, and may date back to the mid
> 2000s...
>
> Any empirical knowledge of whether there remain UAs out there nowadays
> that do
Thanks, Paul. FWIW, B is strictly a UA, not a part-time proxy.
The implementors of A have traced the problem to P's attachment of a value to
the ;lr parameter in the RR:
Record-Route:
They say that's the cause of the breakage.
This view is certainly supported by RFC 3261; its grammar clearly
On 2/9/16 8:58 PM, Alex Balashov wrote:
Hi,
1. I set up a call between two UAs through a proxy:
UAC A > Proxy P1 -> UAS B
2. P1 inserts a Record-Route header indicating that sequential requests
should be directed through it.
3. UAS B does not follow Record-Route properly and, upon
Ankur,
On 02/10/2016 02:01 AM, ankur bansal wrote:
UA will accept it if dialog params matches and its an in dialog request
.Both UA have their own view of dialog information which should be same
ideally but its not checked if request received is from same UAS/proxy
(as per route set stored in d
Hi Alex
UA will accept it if dialog params matches and its an in dialog request
.Both UA have their own view of dialog information which should be same
ideally but its not checked if request received is from same UAS/proxy (as
per route set stored in dialog ).
Also tell me one thing when BYE rece
And yes, I realise that from the vantage point of the BYE request, B is
the UAC and A is the UAS. That was a poor choice of labelling on my part.
On 02/09/2016 08:58 PM, Alex Balashov wrote:
Hi,
1. I set up a call between two UAs through a proxy:
UAC A > Proxy P1 -> UAS B
2. P1
Hi,
1. I set up a call between two UAs through a proxy:
UAC A > Proxy P1 -> UAS B
2. P1 inserts a Record-Route header indicating that sequential requests
should be directed through it.
3. UAS B does not follow Record-Route properly and, upon hanging up,
sends a BYE directly to UA
