I agree with Dale. In addition, having the UAC do it this way makes the
downstream behavior the same whether the recursion on the 300 is done by
the UAC or by a proxy on the path.
Thanks,
Paul
Dale Worley wrote:
> On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote:
>> A question about the CALL-ID.
>>
>> 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc.
>> 2. Redirect server sends response "300 Multiples Choices".
>> 3. UAC makes a pararell search sending three INVITES with CALL-ID:
>> ¿abc?.
>>
>> I dont understand why first INVITE and three last INVITES have the same
>> CALL-ID...
>
> The three INVITEs generated in step 3 are considered to be forks of the
> original INVITE from step 1.
>
> The reason why this is the best way to organize the operation is that
> the UAC only wishes to establish one dialog, with whichever of the
> INVITEs receives a successful response. Since all 4 INVITEs have the
> same call-id, if (through more forking downstream), one UAS receives two
> INVITEs derived from them, it can responds to the second INVITE with
> 482, thus avoiding having the UAS present two copies of the same logical
> call to its user.
>
> Dale
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
