VB: [reSIProcate] PRACK with early media

Jan Granqvist jan_granqvist at yahoo.com
Fri Sep 2 07:34:59 CDT 2016


Ok, now I know. Then we'll have a discussion with our partner.Thank you for your answer Scott.

BR/Janne

     Den onsdag, 31 augusti 2016 20:57 skrev Scott Godin <sgodin at sipspectrum.com>:
 

 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/20160902/4fb17b69/attachment.htm>


More information about the resiprocate-devel mailing list