Hi, I have a scenario where a call is forked through a proxy to an early media announcement server and then subsequently to a SIP provider for actual termination.
Due to the way the RTP relay works on the server side, this results in two different SDP offers from the two respective outgoing branches being sent back to the caller: 1. 183+SDP on branch #1. 2. 183+SDP' on branch #2. 200 OK+SDP' on branch #2. 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. Any insight would be appreciated! -- 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/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors