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