> > 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.
I'd say one transaction and one call leg.
> > If sent, the CANCEL (to UA1) will be part of another call leg (CL1),
> > and any subsequent transactions to UA2 will be part of yet another
> > call leg (CL2).
>
> No.
>
> There will be no CANCEL to UA1. UA0 sends out a CANCEL corresponding
> to its request; if it sent out a CANCEL with a UA1's tag in it, then
> this CANCEL would not be related to any other request (since it would
> not match the original INVITE), and thus UA0 would see a 481.
Okay, so you're saying that UA0 cannot CANCEL one branch that the original
INVITE takes (he can only CANCEL all branches)....sounds good.
> > For a BYE response to UA2 (that needs a corresponding INVITE), CL2
> > may need to "know" CL0.
>
> Sorry, I don't follow this bit.
My understanding is that the BYE must have a larger CSeq than the INVITE to
which it relates, and that CSeq numbers should increment for every
transaction in a call leg. If the original INVITE is part of a different
call leg than the BYE, special consideration must be made for CSeq.
> > Call leg is defined by To, From, Call-ID. Note that when comparing To
> > and From header fields, if there is not tag-param in the request,
> > responses with different tag params will match (i.e. tag-param is
> > not compared unless it is in the request).
>
> I think this relaxation only applies to the To header. From s
> should always exactly match.
Yes, it should always have a tag.
> > The subsequent requests
> > will have a tag-param in the To header, so they will be matched to
> > new call legs.
>
> Indeed.
>
>
> - Jo.
>
>
Jeremy
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
