Re: [reSIProcate] INFO being processed using same transaction state as BYE

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

On Jan 16, 2006, at 08.45, Justin Matthews wrote:

> 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,

Do the INFO and BYE requests contain the magic cookie in the topmost  
Via?
If so, it sounds like the originating UA is broken....

RFC 3261, Sec 8.1.1 Generating the Request ... Vias ...

The branch parameter value MUST be unique across space and time for  
all requests sent by the UA. The ex-
ceptions to this rule are CANCEL and ACK for non-2xx responses. As  
discussed below, a CANCEL request
will have the same value of the branch parameter as the request it  
cancels. As discussed in Section 17.1.1,
an ACK for a non-2xx response will also have the same branch ID as  
the INVITE whose response it ac-
knowledges.

	The uniqueness property of the branch ID parameter, to facilitate  
its use as a transaction ID, was not part of
RFC 2543.

The branch ID inserted by an element compliant with this  
specification MUST always begin with the char-
acters “z9hG4bK”. These 7 characters are used as a magic cookie (7 is  
deemed sufficient to ensure that
an older RFC 2543 implementation would not pick such a value), so  
that servers receiving the request can
determine that the branch ID was constructed in the fashion described  
by this specification (that is, globally
unique). Beyond this requirement, the precise format of the branch  
token is implementation-defined.


Sounds like a problem in the originating  client. It would be very  
expensive (potentially) to fix this in reSIProcate.
Esp. for unknown / extension methods.




Alan Hawrylyshen
reSIProcate Project Administrator
http://sipfoundry.org/reSIProcate/
a l a n a t j a s o m i d o t c o m