Re: [reSIProcate-users] Resiprocate Stack Not Forwarding Certain SIP Messages

[Adam Roach <adam@xxxxxxxxxxx>]

Probably not. The only reason a 491 should be generated is if there's a pending re-invite in the *opposite* direction. See RFC 3261, sections 14.1 and 21.4.27.

/a

On 6/25/19 1:22 PM, Scott Godin wrote:

My best guess is that something is not correct with the ACK the UAC generated for your 488 response.  I suspect the stack is throwing it out and it's not getting to the DUM layer.  When a subsequent reINVITE arrives, DUM thinks the old reINVITE transaction is not yet completed and returns a 491 response.  Examining the stack level logs should determine if this is the case or not.

Scott

On Tue, Jun 25, 2019 at 12:46 PM Adam Roach <adam@xxxxxxxxxxx> wrote:

On 6/25/19 10:37 AM, Edward James wrote:

Hi All,

          I have a SIP message flow in which the Resiprocate stack is a UAS (so the call is inbound to our application called RT-SIP-20 which uses Resiprocate) and it looks like the Resiprocate stack isn’t forwarding certain SIP messages up to the application. Basically the call is as follows:

 

1.    Inbound Audio Call – this is just a standard inbound call and is set up successfully.

2.    The UAC Sends a reINVITE for FAX – so we receive a reINVITE containing FAX SDP offer and we reject this with a 488 as we don’t support it.

3.    The UAC sends an ACK to the 488 which Resiprocate does not forward to our application.

4.    The UAC sends a reINVITE (containing audio SDP) which Resiprocate does not forward to our application and which Resiprocate rejects with a 491.

 

Does anyone know why Resiprocate would not pass on to our application either an ACK to a 488 to a reINVITE or any subsequent reINVITES ? Just for clarity here’s the SIP message flow (RT-SIP-20 is our SIP engine which uses Resiprocate):

 

UAC INVITE SDP=audio --------à Resiprocate --------à RT-SIP-20 UAS

UAC ß-----------------------------  Resiprocate ß-------- RT-SIP-20 UAS 100 Trying

UAC ß-----------------------------  Resiprocate ß-------- RT-SIP-20 UAS 183 Progress SDP=audio & 100rel

UAC PRACK ---------------------à  Resiprocate --------à RT-SIP-20 UAS

UAC ß-----------------------------  Resiprocate ß-------- RT-SIP-20 UAS 200 OK PRACK

UAC ß-----------------------------  Resiprocate ß-------- RT-SIP-20 UAS 200 OK INVITE

UAC ACK ------------------------à  Resiprocate --------à RT-SIP-20 UAS

 

So at this point it’s all good with an audio call set up. Then we get this reINVITE/488/ACK exchange:

 

UAC reINVITE SDP=image --------à Resiprocate --------à RT-SIP-20 UAS

UAC ß--------------------------------  Resiprocate ß-------  RT-SIP-20 UAS 488 Not Acceptable Here

UAC ACK ---------------------------à Resiprocate  ** Not Forwarded to RT-SIP-20 ??? **

It's been a while since I've worked with the stack; but, from a protocol perspective, an ACK to an INVITE failure is not interesting to the application: it's basically a transport-layer acknowledgement, similar to a TCP ACK (which applications don't find out about either). To be clear: ACKs to failure responses are generated hop-by-hop from the upstream proxy, so they can never contain useful information. I suspect (and have a fuzzy memory that this is true) that the stack intentionally doesn't inform the application about them, because they're fundamentally unactionable.

 

So the ACK to the 488 isn’t forwarded to our engine. The we get this reINVITE/491/ACK exchange:

 

UAC reINVITE SDP=audio ---------à Resiprocate ** Not Forwarded to RT-SIP-20 ??? **

UAC ß--------------------------------  Resiprocate 491 Request Pending sent from Resiprocate

UAC ACK ---------------------------à Resiprocate  ** Not Forwarded to RT-SIP-20 ??? **

 

So now it seems that Resiprocate is not forwarding the reINVITE and responding with a 491.

The 491 you show should only happen if your application *sent* a new INVITE in the same dialog and hasn't yet received a response to that INVITE. If that isn't the case, then you may have uncovered a bug of some kind. But the first think I'd do is double-check that you aren't sending an INVITE from your application, since the flow you show isn't that unusual (so a bug like you've described would have likely been uncovered years ago).

/a

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/