Jonathan Rosenberg wrote:
[...]
> > james jack wrote:
> > >
> > > Dear All:
> > > I have one question to ask, the situation is listed
> > > as the following:
> > > User A call User B via Proxy P, User B has three
> > > contact address in the registrar whose domain is the
> > > same as that of the proxy P. So when User A send
> > > INVITE request to User B, this INVITE request will be
> > > forked into three branches,the INVITE request will
> > > reached User B(1),B(2),B(3). the demonstration diagram
> > > is listed as the following:
> > >
> > >
> > > B(1)
> > > A---- P -------B(2)
> > > B(3)
> > > When B(1) receives INVITE request, without sending
> > > 100 response, B(1) sends BYE request to this INVITE
> > > requst, when this request arrives P, according to the
> > > CallLeg, it can match, then what would Proxy P do?
> > > Wait for other B(2),B(3)'s response? Or delete the
> > > corresponding State machine in P? or throw this BYE
> > > request?
> >
> > James:
> >
> > I have a hard time figuring out why a UAS would respond to an
> > INVITE with a BYE without sending any provisional and/or final
> > responses to the INVITE first. The RFC makes it pretty clear
> > that (a) an INVITE elicits a provisional and/or a final response,
> > and (b) a BYE tears down a session previously established; in
> > this case, a session has not been established between B(1) and A.
> >
> > However, if B(1) sends a BYE to P, the BYE will match the
> > "default call leg" i.e. From (maybe with tags), Call-ID, and To
> > (definitely no tags since B(1) never send out a final response
> > to the INVITE). Since proxy P knows that it has responses to
> > two other INVITE pending, it must wait until it gets a "better"
> > response from one of the other UASes.
>
> No, no, no.
>
> Proxies are transactional entities.
> Proxies are transactional entities.
>
> One more time.
>
> Proxies are transactional entities.
>
> The proxy sees the BYE *****as a new transaction******. Processing and
> routing of that BYE would occur as for any transaction, and would complete
> independently of the INVITE.
Jonathan:
Right; I was not suggesting otherwise. Since James seems to have a
pathological UAS that insists on responding to an INVITE with a BYE of its
own, why not have a smart proxy to counterbalance it? Keeping proxies
transactional has many advantages and the correct behaviour would be, as you
state, to process the BYE transaction independent of the INVITE. However,
if there exists a hypothetical UAS (at least I hope it is hypothetical) that
responds with a BYE to an INVITE, then there may well exist a hypothetical
proxy that handles it :-)
> The UAS should not have sent a BYE to begin with, as Vijay points out. But
> thats a different issue.
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
