RE: [reSIProcate] INFO being processed using same transaction state asBYE
Good question - the RFC does seem to indicate that you should be
checking the Send-by parameter and verifying that the Method's match -
although it is not very clear over how mismatches should be handled.
However currently resip only uses the tid for matching - perhaps one of
the core developers has more info to share on resip's implementation. :
)
> -----Original Message-----
> From: Justin Matthews [mailto:jmatthewsr@xxxxxxxxx]
> Sent: Monday, January 16, 2006 11:18 AM
> To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] INFO being processed using same transaction
> state asBYE
>
> Even though this UAC is erroneously reusing the branch-id, resip is
> processing the request in the transaction state for the INFO. Should
> resip
> not match this request to the INFO request because the method names
are
> different (17.2.3, rule 3.)? Is there an appropriate 4xx level
message to
> respond to this request?
>
> Thanks,
>
> -Justin
>
> -----Original Message-----
> From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Sent: Monday, January 16, 2006 11:04 AM
> To: Justin Matthews; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] INFO being processed using same transaction
> state
> asBYE
>
> Yes - the sender should not be reusing the same branch parameter for 2
> separate transactions. Because of the transaction id reuse - the
stack
> see's the BYE as a retransmission of the INFO message.
>
> > -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-
> > devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Justin Matthews
> > Sent: Monday, January 16, 2006 10:45 AM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [reSIProcate] INFO being processed using same transaction
> state
> > asBYE
> >
> > Hello,
> >
> > After a call has been established, if an INFO message is
> received by
> > resip (UAS) and then a BYE is received immediately afterwards
without
> the
> > TU
> > processing the INFO, the BYE is ignored.
> > (TransactionState::processServerNonInvite ~line 795)
> >
> > This is happening because resip determines that the transaction ID's
> of
> > the
> > two messages are the same. The transaction state is TRYING because
of
> the
> > previous INFO.
> >
> > The INFO message has the same branch parameter as the BYE in the top
> via,
> > but the method names are different. (RFC 3261 17.2.3) Is resip
> handling
> > this correctly?
> >
> > Here is the entire call sequence:
> >
> > UAC (grandstream) <-> UAS (resip/dum/myapp)
> > INVITE------------------>
> > TRYING<-----------------
> > 200 OK<-----------------
> > ACK--------------------->
> > INFO-------------------->
> > BYE--------------------->
> > <NO response from resip>
> >
> > Thanks,
> >
> > -Justin
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel