[Users] Accounting wrong BYEs
klaus.mailinglists at pernau.at
Thu Jul 20 10:13:46 CEST 2006
Bogdan-Andrei Iancu wrote:
> Hi Klaus,
> it does sounds like a realistic scenario.
> First of all the UAC may not discover all the branches based on To-tag -
> there might be branches that haven't sent any reply, or replies were
> absorbed by the forking server (ex: 180 after 183 will not be relayed).
Really? Why not? This is strictly valid and make sense. All gateways
INVITE --> SETUP
183 <-- PROGRESS w/ inband audio
180 <-- ALERTING
> Even so, when the BYE is generated, you cannot route it properly to the
> callee set because you do not have a unique routing set for the path.
The client will have a route set for each early dialog.
> Different sets may be returned by each branch; also until the final
> reply the mirroring of RR hdrs is not mandatory. So there is the problem
> how to deliver the BYE to all the branches.
This might be a problem. But it is mandatory for 18x:
Record-Route 2xx,18x mr
> Even so, it suppose that the UAS understands a BYE before 200 OK and is
> able to f proper filtering based on the to tag parameter. Not sure how
> many clients will do this.
This will be a problem too.
> again, I do not say is not possible, but I find it highly unrealistic.
> Klaus Darilion wrote:
>> Bogdan-Andrei Iancu wrote:
>>> not sure if this makes sends - how the UAC is aware of the parallel
>>> forking? the fork is transparently done by the proxy and it is the
>>> only one to manage the branches.
>> Not sure about this, but what about:
>> If it receives several 180/183 with different to-tags, the client has
>> to maintain several dialogs in "early-dialog" state.
>> If the UAC sends the BYE in-dialog, it gets routed to the proper UAS,
>> which will response to the INVITE dialog with 487 Request terminated.
>> This should cancel this single branch inside the proxy.
More information about the sr-users