< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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