> 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.
> 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.
> For a BYE response to UA2 (that needs a corresponding INVITE), CL2
> may need to "know" CL0.
Sorry, I don't follow this bit.
> 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.
> The subsequent requests
> will have a tag-param in the To header, so they will be matched to
> new call legs.
Indeed.
- Jo.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
