Hi,
I've got a scenario where call branch #1 goes to an in-call announcement server; the message is played out via unidirectional early media (183+SDP), then that branch is disposed of with a 503. A subsequent call then goes out to the real SIP provider that will ultimately answer the call.
There's some trouble handling this with RTPEngine:
Two subsequent calls to rtpengine_offer() in a normal request route context will result in two SDP message lumps concatenated in the second INVITE (to the provider).
This can be fixed by putting the rtpengine_offer() invocations into branch routes. However, the next problem is that then the identical offer goes to the second callee with no regard for RTPEngine's internal state, so RTPEngine ends up transmitting from a different port to the one that is declared in the SDP offer, requiring NAT latching from the provider to achieve proper symmetry in the return stream.
This can be fixed with:
rtpengine_offer("replace-origin replace-session-connection ICE=remove via-branch=1 internal external");
And in the reply handling:
rtpengine_answer("replace-origin replace-session-connection ICE=remove via-branch=2");
An alternative to using via-branch[1] is to simply delete the call before initiating branch #2:
rtpengine_delete("delete-delay=0"); rtpengine_offer("replace-origin replace-session-connection ICE=remove internal external");
However, both of these lead to the problem that caller receives two distinct SDP answers on the respective branches.
I am not sure offhand whether this is a protocol semantics violation. On the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.
So, I always understood that the first answer is the final answer, absent a session-updating request cycle. On the other hand, RFC 3960 ("Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an application server to establish early media sessions with the UAC. The UAC indicates support for the early-session disposition type (defined in [2]) using the early-session option tag. This way, UASs know that they can keep offer/answer exchanges for early media (early-session disposition type) separate from regular media (session disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to 3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs will handle this situation.
So, what I would most prefer is a means of recycling the same answer port on the "back" side of RTPEngine while pivoting it on the front across branches/multiple offers.
Is that possible? If so, how can it be achieved?
Many thanks,
-- Alex
[1] As best as I understood how to use it; the documentation is a bit unclear!
Not sure if you've tried, but would RTPengine's loop-protect help with the duplicate session description I. The second branch?
-
Alex Balashov -
Anthony Messina