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

Re: [reSIProcate] PRACK with early media


It is not legal to repeat the SDP answer in a subsequent reliable 18x.  Technically this should be treated as a new offer.  However that flow that flow is highly discouraged.  Subsequent offer/answer exchanges are recommended to be done via UPDATE messaging instead.

Here are comments from the MasterProfile header file about the UAC PRACK support:
      // UAC PRACK support.  UPDATE must be enabled(currently defaults to on, do
      // not disable w/out disabling UAC PRACK support).
      //
      // Flows where an an answer is received in a 180rel and subsequent O/A
      // exchanges using UPDATE occur in the early dialog
      // have been tested.
      //
      // A subsequent O/A exchange using 180rel/PRACK is also supported. This is
      // a really bad idea, as an answer must be generated; the offer cannot be
      // rejected. UPDATE should always be used for O/A exchanges once the
      // dialog is established.
      // 
      // Invite/18x(offer)/PRACK(ans) also works
      // 
      // Invite(offer)/18x(ans)/PRACK(offer)/200P(ans) issupported, but not recommended.  
      // The UAC MUST call provideOffer from the onAnswer callback in order to generate 
      // the offer in the PRACK.
      //
      // Explicit limitations are:
      // - Overlapping reliable provisional responses that contain a body are not
      //   handled.
      //
      // Note:  Using SupportedEssential is exactly the same as using Supported, 
      //        SupportedEssential only effects UAS Prack implementation

All that being said - the text doesn't seem to indicate explicitly that your scenario isn't support (assuming the 2nd reliable 183 SDP is treated as a new offer) - it is just discouraged.  If this is the case I suspect you can pin point the issue in the code, by following the log file output and the code logic in ClientInviteSession to track down exactly what is happening (hint:  look at dispatchEarlyWithAnswer).  If indeed the 2nd 183 is not intended to be a new offer, then I would say your scenario is invalid. 

Scott

On Wed, Aug 31, 2016 at 6:15 AM, Jan Granqvist via resiprocate-devel <resiprocate-devel@xxxxxxxxxxxxxxx> wrote:
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

---------- Forwarded message ----------
From: Jan Granqvist <jan_granqvist@xxxxxxxxx>
To: "resiprocate-devel@xxxxxxxxxxxxxxx" <resiprocate-devel@xxxxxxxxxxxxxxx>
Cc: 
Date: Wed, 31 Aug 2016 09:43:05 +0000 (UTC)
Subject: PRACK with early media
Hi all,

I've run into some problem(?) with PRACK towards a SIP trunk which support early media.
The SIP trunk(UAS) responds to an INVITE with a 183 Session Progress to which the SIP trunk requires PRACK.
The DUM acknowledge this and sends a PRACK to which the SIP trunk responds with a 200 OK.

At this point the SIP trunk sends a new 183 Session Progress including the previous SDP as well as stepping up the RSeq.
This signal the DUM doesn't PRACK, and so the SIP trunk keeps re-transmitting the signal.


UAC                                           UAS(Sip trunk)
 |------------------INVITE(offer)-------------->|
 |<------------------100 Trying-----------------|
 |<----183 Session Progress(answer)---|
 |--------------------PRACK------------------->|
 |<------------------200 OK---------------------|
 |<----183 Session Progress(answer)---|
 |<----183 Session Progress(answer)---|
 |<-----------504 Server Time-out-----------|
 |-----------------------ACK-------------------->|

Now is this a valid case? What am I missing?

I'm using version 1.10.0.

BR
/Janne