Jo Hornsby wrote:
>> Where is it stated that call legs are only spawned by 2xxs?
>
>
> Hmmm.... The best I could come up with was 11.3:
> "Multiple responses may arrive at the UAC for a single INVITE
> request, due to a forking proxy. Each response is
> distinguished by the "tag" parameter in the To header field,
> and each represents a distinct call leg."
> But you're right -- this doesn't preclude 1xxs.
>
> Still, it just sits right with me that only 2xxs spawn call
> legs. I can see a case for 1xxs if someone wields the mighty
> axe of PRACK; however, doesn't that then suggest that a BYE
> needs to be sent if the "call leg" set up by some 1xx ultimately
> resulted in some non-2xx definitive? I don't see it, meself.
Upon further thinking, now I believe that 1xx responses do create call
legs, at least for proxy servers. Let's say in my example, UA1 does not
send any 4xx or 6xx responses after the 180 tag=1. Then PS receives 200
from UA2. What PS should do next is send CANCEL to UA1 because there is
a pending request on that call leg. And the very reason PS does that is
because a call leg has been set up by the 180 tag=1 from UA1.
deleted...
>
>> My question will be solved if we can convince ourselves that only 2xxs
>> spawn call legs. In this case, UA0 just ignores 180 tag=1. However, if
>> 1xx responses can also create call legs, then I believe UA0 still has a
>> transaction that is pending.
>
>
> No, this is not right in any case: a single initial INVITE
> can result in 0 or more Call Legs; however, there is still
> only one transaction.
>
>
>
According to bis-02, "A transaction is identified by the CSeq sequence
number within a single call leg" (Section 1.4). I think this means that
different call legs can not share same transaction. If you can show
that in my example, there is only transaction, then I won't have
ambiguity with UA0's behavior.
Regards,
Shan Lu
NexTone Communications
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
