> > 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?
The key is "match up." The BYE must have a tag (in the To header) for the
forking proxy to know where to send it. Consider the case where you have
multiple 2xx (in the example, from UA1 and UA2) to the INVITE. Say, you ACK
both (the ACKs must have the same CSeq as the INVITE, but they are part of
seperate call legs because of the To tag). Now you want to BYE UA1. How do
you match the ACK and BYE (to UA1) to the INVITE? Is the INVITE part of
both call legs?
> - Jo.
>
>
Jeremy
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
