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

[Edward James <ERJ@xxxxxxxxxxxxxxx>]

Hi Scott and Adam,

          Thanks for your help, we’ve figured out what’s happening. The stack is intentionally not forwarding the ACK to the 488 back up to our application and our application then considers the reINVITE to be still ongoing when the next reINVITE comes in and it replies to it with a 491 which looking at https://tools.ietf.org/html/rfc3261#section-14.2 might be incorrect as it didn’t send the first reINVITE it received it.

 

So I’m thinking the following:

 

1.       When we send the 488 (or any 4xx) we also do the logic that would have been done if we’d received the ACK and then the subsequent reINVITEs would work.

2.       Possibly send something other than a 491 in response to a received reINVITE when we are still processing a reINVITE we previously received. Any suggestions what we should send ? The RFC is quite clear if the previous reINVITE was sent by us as follows:

 

A UAS that receives an INVITE on a dialog while an INVITE it had sent

   on that dialog is in progress MUST return a 491 (Request Pending)

   response to the received INVITE.

 

It’s not as clear to me what we should do if it receives an INVITE on a dialog while an INVITE it had received on that dialog is in progress.

 

Regards

Ed

 

 

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