[reSIProcate] PRACK with early media II

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Janne,

Yes I believe you are reading the RFC correctly, and that resiprocate/dum could decide to ignore the illegal SDP.  Note:  The text in your log statements below is a little off, since one side of the "if" statement is when they are NOT identical.  There is at least one of other case in the RFC where it recommend to ignore as well.  I will look at these and try to get a change committed to GIT.

Thanks,

Scott

On Mon, Dec 18, 2017 at 9:58 AM, Jan Granqvist <jan_granqvist@xxxxxxxxx> wrote:

Hi Scott,

Sorry for addressing you directly and not through the resiprocate mailing list, but no one did reply.

But, we do have this burning issue and we need an advice on the subject.

Referring to rfc6338, we think that the UAC should ignore any included sdp in the 2xx response(F12)

In method ClientInviteSession::dispatchEarlyWithAnswer, we suggest something like this:

      case On2xxOffer:

         {

             if (*offerAnswer == *mCurrentRemoteOfferAnswer)

             {

                 InfoLog (<< "Ignoring illegal offer identical with current remote offer/answer");

             }

     else

     {

 InfoLog (<< "Ignoring illegal offer identical with current remote offer/answer" << msg.brief());

      }

      transition(Connected);

      sendAck();

      handleFinalResponse(msg);

      onConnectedAspect(getHandle(), msg);

      break;

         }

Thanks in advance

BR

/Janne

Den torsdag, 26 oktober 2017 11:10 skrev Jan Granqvist <jan_granqvist@xxxxxxxxx>:

Hi all,

I have an interop issue towards a sip trunk which requires PRACK.

The problem is triggered by the fact that the sip trunk includes a slightly modified sdp in the final 

response.

That is:

UAC                                          UAS(Sip trunk)

|------------------INVITE(sdpA)-------------->|

|<------------------100 Trying----------------|

|<----------183 Session Progress(sdpB)--------|

|--------------------PRACK------------------->|

|<------------------200 OK--------------------|

|<---------------180 Ringing(sdpB)------------|

|--------------------PRACK(sdpA)------------->|

|<------------------200 OK(sdpB)--------------|

|<------------------200 OK(sdpB')-------------|    <-- offending sdp

The difference within the sdpB' is that the sip trunk increased its version id.

This sdpB' is considered a new offer(ClientInviteSession::dispatchEarlyWithAnswer)

and had it not been for the increased version id, DUM would have allowed the

offer(although disregard it) and allowed the connection.

I don't know why the SIP trunk keeps increasing the version id.

In rfc6337 at the end of section 3.1.1, I found the following:

  The UAS does not include SDP in responses F9 and F12.  However, the

  UAC should prepare to receive SDP bodies in F9 and/or F12, and just

  ignore them, to handle a peer that does not conform to the

  recommended implementation.

Does the last sentence really mean that DUM actually should ignore the last sdp and not terminate the 

call, and thereby overcome 'a peer not conforming to the recommended implementation'?

TIA

/Janne