[SR-Users] RTPEngine serial forking with early media

[Alex Balashov]

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!

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/