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