> > > > 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.
> >
> > The forking proxy will know where to send it because the BYE will
> > either have Route header(s), or the Request-URI will contain
> > the SIP URL from the appropriate Contact.
> >
> > > 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).
> >
> > Indeed.
> >
> > > 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?
> >
>
> When constructing the BYE to UA1, UA0 needs to know which INVITE it
> corresponds to (likewise, for UA2).
Oh very much so. Still, that's UA0's responsibility; noone
elses.
> > Proxies do not know about call legs; they only speak transactions.
>
> Stateless proxies only speak transactions. Stateful proxies know about
> calls, call setups, sesssions or some other abstraction of related
> transactions.
No. Stateful proxies only know about transactions. You may
have a proxy that has a bigger view; she is not defined in
the spec.
- Jo.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
