[reSIProcate] PRACK with early media

[Scott Godin]

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 at resiprocate.org> wrote:

> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> ---------- Forwarded message ----------
> From: Jan Granqvist <jan_granqvist at yahoo.com>
> To: "resiprocate-devel at resiprocate.org" <resiprocate-devel at resiprocate.org
> >
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20160831/cd36f687/attachment.htm>