Hi Liviu, Thank you for your answer. However, I’m afraid I still don’t quite understand — perhaps it is a matter of being thick-skulled, and if so, for that I apologise in advance.
What exactly can be remediated by the caller that cannot be addressed by the parties simply agreeing on a codec through the normal initial invite offer process? The only scenario I can think of offhand is if the caller wishes to truly constrain the stream to a single codec, but is flexible about what codec that should be—just that there is a policy of settling on just one. But I am unsure of why this would be practically desirable. — Sent from mobile, with due apologies for brevity and errors. > On Apr 23, 2019, at 3:37 PM, Liviu Chircu <li...@opensips.org> wrote: > > 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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
