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