Hi Alex, In my experience, late SDP negotiation has proved to be an essential mechanism for codec transcoding. For example, given this setup:
UA-1 B2BUA UA-2 | INVITE | INVITE | |------------------>|--------------------->| | (offer) | (empty) | | | | | | 200 OK | | |<---------------------| | | (offer) | | | | the importance of late SDP offers becomes immediately obvious. By removing the outgoing SDP on the B leg and receiving yet another SDP offer from UA-2, the B2BUA puts itself in a position where it has a high degree of control over the session setup. Some ideas which come to mind: * the ability to intersect codecs * the ability to detect codec incompatibilities and remediate, through transcoding hardware/software, a session setup which would have otherwise ended prematurely with a 488 (Not Acceptable Here) Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 23.04.2019 20:48, Alex Balashov wrote:
Hi, Trying to fill a gaping hole in my knowledge: What is the actual purpose of late SDP offers (no SDP in initial INVITE, SDP offer in 2xx reply, SDP answer in end-to-end ACK)? RFC 3261 mentions them, of course, but I’ve only ever seen them used in Cisco (CCM and IOS voice gateway) land. I understand that this puts some control in the hands of the caller - it gives the caller the flexibility to respond based on the callee's SDP offer more 'flexibly', since it doesn't have to tip its hand about what it wants first. But from what I understand, an SDP stanza is, in principle, a statement about what / how each endpoint wants to receive, not send. Right? I am aware that there are some cases where, as a matter of convention more so than standardisation, some inferences about sending intentions are permitted on the basis of an SDP advertisement -- such as the 183 early media case. Still, in principle, SDP is about what I want to receive and how I want to receive it, I thought. And in principle, any session can involve wildly asymmetric and non-isomorphic media stream characteristics, i.e. two different codecs, packetisation durations, etc. on the respective legs. If so, what purpose does it serve for the caller to not have to tip its hand preemptively about what codecs it is willing to accept, for example? Does it mirror some PSTN interoperability need? A lot of the discussion around it seems to be in the context of third-party call control (3pcc), but the exact connection is unilluminated, and in any case, that's not a concept I understand particularly well. Much technical discussion exists online about what it does and why it needs to be supported: it allows the caller to respond flexibly based on the callee’s offer. But I can't find a word about why one might actually want to do that, what sort of scenario it is meant to support, or otherwise anything about the underlying philosophical motivation. Any insight is appreciated! -- Alex
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors