[SR-Users] RTPEngine serial forking with early media

[Anthony Messina]

Not sure if you've tried, but would RTPengine's loop-protect help with the duplicate session description I. The second branch?
-- 
Anthony

On July 16, 2018 11:51:43 AM CDT, Alex Balashov <abalashov at evaristesys.com> wrote:
>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/
>
>_______________________________________________
>Kamailio (SER) - Users Mailing List
>sr-users at lists.kamailio.org
>https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users