Re: [Sip-implementors] The purpose of late offers
Hi Roman, On Tue, Apr 23, 2019 at 05:33:37PM -0400, Roman Shpount wrote: > The most basic use case is click-to-call scenario. You have a web site or > an application that imitates a call between two SIP end points. User clicks > the web site which causes some sort of SIP application server to send an > INVITE without an offer sent to SIP end point 1. SIP application server > gets the answer with the SDP offer in 200 OK response to the initial INVITE > to end point 1, and then sends this offer to SIP end point 2. SIP End point > 2 answers the call with answer in the SDP in 200 OK response. SIP > Application server send the answer from end point 2 in ACK to SIP end point > 1. As a result, SIP signaling flow goes through SIP application server, but > media goes direct between SIP end points 1 and 2. I think I'm starting to understand what you and Paul are saying. There's nothing to offer in the initial INVITE, so you're asking one of the endpoints to provide the offer that starts the process instead. That seems obvious in hindsight, but I hadn't really considered it, since most of the click-to-call type scenarios I'm familiar with use the INVITE-hold-REFER approach. Thanks a lot, guys! -- Alex -- 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
Re: [Sip-implementors] The purpose of late offers
I still don't get it, I'm sorry: On Tue, Apr 23, 2019 at 05:34:21PM -0400, Paul Kyzivat wrote: > 1) it doesn't have any idea what codecs, or even what media, either of > the endpoints support. Yes, but how does a late offer confer this knowledge in some materially different way to a normal one? > 2) since it isn't planning on terminating the media it has no media > address to include in an initial offer. If it isn't planning on terminating the media, why wouldn't it just pass through the SDP offer from the caller as-is, as any proxy or B2BUA (sans integrated media apparatus) would? In other words, what exactly is being accomplished for the benefit of a third-party call controller via a late offer that can't be accomplished via a normal one? -- 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
Re: [Sip-implementors] The purpose of late offers
On 4/23/19 5:12 PM, Alex Balashov wrote: Paul, Why can’t it do that with an offer in the initial invite? Because: 1) it doesn't have any idea what codecs, or even what media, either of the endpoints support. 2) since it isn't planning on terminating the media it has no media address to include in an initial offer. Thanks, Paul — Sent from mobile, with due apologies for brevity and errors. On Apr 23, 2019, at 5:10 PM, Paul Kyzivat wrote: Alex, A classic use case is 3PCC: A device in the middle wants to broker a call between two other endpoints. A priori it doesn't know the capabilities of either of those endpoints, and doesn't want to put itself in the media path as a transcoder. So it asks one end to provide an offer so it can offer that to the other end. Thanks, Paul On 4/23/19 1:48 PM, 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 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] The purpose of late offers
Alex, The most basic use case is click-to-call scenario. You have a web site or an application that imitates a call between two SIP end points. User clicks the web site which causes some sort of SIP application server to send an INVITE without an offer sent to SIP end point 1. SIP application server gets the answer with the SDP offer in 200 OK response to the initial INVITE to end point 1, and then sends this offer to SIP end point 2. SIP End point 2 answers the call with answer in the SDP in 200 OK response. SIP Application server send the answer from end point 2 in ACK to SIP end point 1. As a result, SIP signaling flow goes through SIP application server, but media goes direct between SIP end points 1 and 2. Regards, _ Roman Shpount On Tue, Apr 23, 2019 at 5:13 PM Alex Balashov wrote: > Paul, > > Why can’t it do that with an offer in the initial invite? > > — > Sent from mobile, with due apologies for brevity and errors. > > > On Apr 23, 2019, at 5:10 PM, Paul Kyzivat wrote: > > > > Alex, > > > > A classic use case is 3PCC: A device in the middle wants to broker a > call between two other endpoints. A priori it doesn't know the capabilities > of either of those endpoints, and doesn't want to put itself in the media > path as a transcoder. So it asks one end to provide an offer so it can > offer that to the other end. > > > >Thanks, > >Paul > > > >> On 4/23/19 1:48 PM, 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 > ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] The purpose of late offers
Paul, Why can’t it do that with an offer in the initial invite? — Sent from mobile, with due apologies for brevity and errors. > On Apr 23, 2019, at 5:10 PM, Paul Kyzivat wrote: > > Alex, > > A classic use case is 3PCC: A device in the middle wants to broker a call > between two other endpoints. A priori it doesn't know the capabilities of > either of those endpoints, and doesn't want to put itself in the media path > as a transcoder. So it asks one end to provide an offer so it can offer that > to the other end. > >Thanks, >Paul > >> On 4/23/19 1:48 PM, 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
Re: [Sip-implementors] The purpose of late offers
Alex, A classic use case is 3PCC: A device in the middle wants to broker a call between two other endpoints. A priori it doesn't know the capabilities of either of those endpoints, and doesn't want to put itself in the media path as a transcoder. So it asks one end to provide an offer so it can offer that to the other end. Thanks, Paul On 4/23/19 1:48 PM, 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
Re: [Sip-implementors] The purpose of late offers
If we are strictly discussing the interaction between two UAs, then I am at a loss as well regarding the practical usefulness of late SDP offers and would be interested in hearing other opinions. However, when we have the third, middling party is where things get interesting. Take, for example, a SIP operator intending to achieve interoperability between two "stubborn" carriers it is interconnected with. One carrier only does G.711, while the other one only does G.729. The only solution is to take control of session establishment with the mechanism I described earlier when routing to and from these two, and transcode the stream of one of the parties by using the other parties' codec. Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 23.04.2019 22:43, Alex Balashov wrote: 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 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-1B2BUA 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/mailma
Re: [Sip-implementors] The purpose of late offers
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 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-1B2BUA 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
Re: [Sip-implementors] The purpose of late offers
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
