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 <[email protected]> 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 >[email protected] >https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
