[Users] Accounting wrong BYEs

[Klaus Darilion]

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 
does this:
   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.

regards
klaus

> again, I do not say is not possible, but I find it highly unrealistic.
> 
> regards,
> bogdan
> 
> 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.
>