> > > 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.
No. One transaction. There will be one call leg for each
distinct (i.e., has a different tag in the To header) 2xx;
and not before.
> 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.
I don't see how the BYE can be from a different call leg?
If it doesn't match up { From, To, Call-ID }-wise, then it's
effectively random, and you just 481, right?
> > > 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.
Yeah (this is a MUST now, isn't it?), but as always, we
have to be ready for older UAs.
- Jo.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
