> >> In this example, the INVITE and all responses, regardless of which UA
> >> (UA1 or UA2) sent them, will be part of one call leg (CL0).
> >
> > Uh. I'd be careful here. More they're part of one transaction.
> > Call Legs are spawned by 2xxs.
>
> 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.
> I think you are right. I was wrong in my original posting that UA0 sent
> out CANCEL to UA1. In fact, CANCEL should have Call-ID, To, From, and
> CSeq (numeric) fields identical to the initial INVITE. Also, the CANCEL
> must not use the Contact contained in 180 tag=1. Rather, it must follow
> the same path as INVITE, in which case it would have been sent to PS.
Yes; i.e., the Request-URI should be identical, too.
> Bis-02 further states that a proxy that receives a CANCEL forwards it to
> all branches with pending requests. And in my example, there was none
> from PS point of view. So, CANCEL will do no good.
Indeed.
> 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.
- Jo.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
