Re: [OpenSIPS-Devel] media proxy with sangoma
Hi Richard, I wasn't at ClueCon but I'm currently testing one of those boards. My previous question about the media-proxy dispatcher protocol was to try and implement a proof of concept of this. Who did you talk to from Sangoma ? I would gladly add a little bit more weight to your demand ;-) Best regards, Dominique Le 26 août 2010 à 15:40, Richard Revels a écrit : Bogdan and Saul (or anyone else for that matter), Good morning. I was wondering if either of you had been approached by Sangoma at the ClueCon Convention? They have a transcoding board that seems fairly inexpensive per channel. I mentioned I would be quite interested if they did some work to make it accessible in conjunction with the media dispatcher and I had the impression they were open to the idea. Saul, I'm now thinking my previous posting about the media dispatcher and re-invites might have been a problem with me not capturing all the streams rather than the media relay not forwarding correctly. I expect to be testing with that again early next week. Sorry to have left it hanging for this long. Richard ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] media proxy with sangoma
Hi Richard and Dominique, On 08/26/2010 03:47 PM, Dominique Broeglin wrote: Hi Richard, I wasn't at ClueCon but I'm currently testing one of those boards. My previous question about the media-proxy dispatcher protocol was to try and implement a proof of concept of this. Who did you talk to from Sangoma ? I would gladly add a little bit more weight to your demand ;-) Best regards, Dominique Le 26 août 2010 à 15:40, Richard Revels a écrit : Bogdan and Saul (or anyone else for that matter), Good morning. I was wondering if either of you had been approached by Sangoma at the ClueCon Convention? They have a transcoding board that seems fairly inexpensive per channel. I mentioned I would be quite interested if they did some work to make it accessible in conjunction with the media dispatcher and I had the impression they were open to the idea. Saul, I'm now thinking my previous posting about the media dispatcher and re-invites might have been a problem with me not capturing all the streams rather than the media relay not forwarding correctly. I expect to be testing with that again early next week. Sorry to have left it hanging for this long. In the current MediaProxy version (MediaProxy 2) packets are not handled in userspace, a conntrack rule is inserted and the kernel itself is doing the relaying of packets. While there might be way of sitting in the middle of the packets, I'm not curently aware of it but that looks like the way to start. Now, assuming that the RTP transcoding can be done, I guess the SDP will also need to be mangled to 'fool' the other endpoint and making him believe he is using a different codec. Or, are you thinking about another scenario? -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] media proxy with sangoma
Scott Daly, Sales. Konrad, Engineering. On Aug 26, 2010, at 9:47 AM, Dominique Broeglin wrote: Hi Richard, I wasn't at ClueCon but I'm currently testing one of those boards. My previous question about the media-proxy dispatcher protocol was to try and implement a proof of concept of this. Who did you talk to from Sangoma ? I would gladly add a little bit more weight to your demand ;-) Best regards, Dominique Le 26 août 2010 à 15:40, Richard Revels a écrit : Bogdan and Saul (or anyone else for that matter), Good morning. I was wondering if either of you had been approached by Sangoma at the ClueCon Convention? They have a transcoding board that seems fairly inexpensive per channel. I mentioned I would be quite interested if they did some work to make it accessible in conjunction with the media dispatcher and I had the impression they were open to the idea. Saul, I'm now thinking my previous posting about the media dispatcher and re-invites might have been a problem with me not capturing all the streams rather than the media relay not forwarding correctly. I expect to be testing with that again early next week. Sorry to have left it hanging for this long. Richard ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] media proxy with sangoma
I was thinking the media relay would modify the SDP as per normal but set the trancoder IP/port as one side (user configurable?) of the audio stream rather than itself. Then it would tell the transcoder to send to itself so the packets could be forwarded to the endpoints as usual. And now that I reread your email, having the connection tracking rules send and receive from the transcoder in the middle of the two sides of the media relay would be much nicer. The SDP would still have the relay IP/ports advertised to each side. Good point about the whole SDP mangling thing. I was thinking only of the case where you know, say, G-729 is available on one side and not the other. You know you need transcoding so you send rtp through the transcoder and tell each side it is using what it wanted. In reality the SDP has to be looked at from both ends and then a choice made to use the transcoder if nothing matches, and then modify the SDP for the far end to reflect what it is getting. It would not be desired to send rtp streams through the transcoder if both sides were already supporting a given codec. I bet this gets a lot more complicated than I was picturing up until now. : However, I'm thinking there might be a demand for this so Sangoma may have a compelling reason to invest the work required for it. Richard On Aug 26, 2010, at 9:58 AM, Saúl Ibarra Corretgé wrote: Hi Richard and Dominique, On 08/26/2010 03:47 PM, Dominique Broeglin wrote: Hi Richard, I wasn't at ClueCon but I'm currently testing one of those boards. My previous question about the media-proxy dispatcher protocol was to try and implement a proof of concept of this. Who did you talk to from Sangoma ? I would gladly add a little bit more weight to your demand ;-) Best regards, Dominique Le 26 août 2010 à 15:40, Richard Revels a écrit : Bogdan and Saul (or anyone else for that matter), Good morning. I was wondering if either of you had been approached by Sangoma at the ClueCon Convention? They have a transcoding board that seems fairly inexpensive per channel. I mentioned I would be quite interested if they did some work to make it accessible in conjunction with the media dispatcher and I had the impression they were open to the idea. Saul, I'm now thinking my previous posting about the media dispatcher and re-invites might have been a problem with me not capturing all the streams rather than the media relay not forwarding correctly. I expect to be testing with that again early next week. Sorry to have left it hanging for this long. In the current MediaProxy version (MediaProxy 2) packets are not handled in userspace, a conntrack rule is inserted and the kernel itself is doing the relaying of packets. While there might be way of sitting in the middle of the packets, I'm not curently aware of it but that looks like the way to start. Now, assuming that the RTP transcoding can be done, I guess the SDP will also need to be mangled to 'fool' the other endpoint and making him believe he is using a different codec. Or, are you thinking about another scenario? -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] media proxy with sangoma
Hi, On 08/26/2010 04:31 PM, Richard Revels wrote: I was thinking the media relay would modify the SDP as per normal but set the trancoder IP/port as one side (user configurable?) of the audio stream rather than itself. Then it would tell the transcoder to send to itself so the packets could be forwarded to the endpoints as usual. Alright, putting the transcoder between the network and the relay could do. However... And now that I reread your email, having the connection tracking rules send and receive from the transcoder in the middle of the two sides of the media relay would be much nicer. The SDP would still have the relay IP/ports advertised to each side. Good point about the whole SDP mangling thing. I was thinking only of the case where you know, say, G-729 is available on one side and not the other. You know you need transcoding so you send rtp through the transcoder and tell each side it is using what it wanted. In reality the SDP has to be looked at from both ends and then a choice made to use the transcoder if nothing matches, and then modify the SDP for the far end to reflect what it is getting. It would not be desired to send rtp streams through the transcoder if both sides were already supporting a given codec. ... lets assume the standard scenario: Alice calls Bob. Alice offers G711, G722 and G729. When the INVITE arrives at the proxy and *before* it goes out to Bob, MediaProxy module kicks in and mangles the SDP. At this point we don't know what Bob's answer will be, so what should we put in there, the transcoder IP and port or the relay? We can only know this once Bob answers, but the it'd be too late to activate MediaProxy for Alice. I bet this gets a lot more complicated than I was picturing up until now. : Feels like it ;-) However, I'm thinking there might be a demand for this so Sangoma may have a compelling reason to invest the work required for it. In a B2BUA scenario this would make more sense, since you can start without the transcoder and if you detect it's needed, you could reINVITE both parties and put the transcoder in the middle. In a proxy scenario, OTOH, I find it utterly complicated. Anyway, don't take my word for granted, there could be something obvious which I am overlooking here. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] media proxy with sangoma
Hi, My idea was to parse the SDP and determine if transcoding is needed on the invite and/or on the responses. Then given what is read, if transcoding is required: Alice --- media-proxy --- transcoding card --- media-proxy --- Bob if no transcoding is required: Alice --- media-proxy --- Bob It's the simplest way I found to be able to decide to use transcoding or not on the fly. What do you think of this approach ? I agree it's complicated but re-INVITEs come with their own issues in heterogeneous environments. Best regards, Dominique Le 26 août 2010 à 16:44, Saúl Ibarra Corretgé a écrit : Hi, On 08/26/2010 04:31 PM, Richard Revels wrote: I was thinking the media relay would modify the SDP as per normal but set the trancoder IP/port as one side (user configurable?) of the audio stream rather than itself. Then it would tell the transcoder to send to itself so the packets could be forwarded to the endpoints as usual. Alright, putting the transcoder between the network and the relay could do. However... And now that I reread your email, having the connection tracking rules send and receive from the transcoder in the middle of the two sides of the media relay would be much nicer. The SDP would still have the relay IP/ports advertised to each side. Good point about the whole SDP mangling thing. I was thinking only of the case where you know, say, G-729 is available on one side and not the other. You know you need transcoding so you send rtp through the transcoder and tell each side it is using what it wanted. In reality the SDP has to be looked at from both ends and then a choice made to use the transcoder if nothing matches, and then modify the SDP for the far end to reflect what it is getting. It would not be desired to send rtp streams through the transcoder if both sides were already supporting a given codec. ... lets assume the standard scenario: Alice calls Bob. Alice offers G711, G722 and G729. When the INVITE arrives at the proxy and *before* it goes out to Bob, MediaProxy module kicks in and mangles the SDP. At this point we don't know what Bob's answer will be, so what should we put in there, the transcoder IP and port or the relay? We can only know this once Bob answers, but the it'd be too late to activate MediaProxy for Alice. I bet this gets a lot more complicated than I was picturing up until now. : Feels like it ;-) However, I'm thinking there might be a demand for this so Sangoma may have a compelling reason to invest the work required for it. In a B2BUA scenario this would make more sense, since you can start without the transcoder and if you detect it's needed, you could reINVITE both parties and put the transcoder in the middle. In a proxy scenario, OTOH, I find it utterly complicated. Anyway, don't take my word for granted, there could be something obvious which I am overlooking here. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] media proxy with sangoma
On 08/26/2010 04:53 PM, Dominique Broeglin wrote: Hi, My idea was to parse the SDP and determine if transcoding is needed on the invite and/or on the responses. Then given what is read, if transcoding is required: Alice --- media-proxy --- transcoding card --- media-proxy --- Bob if no transcoding is required: Alice --- media-proxy --- Bob But by the time you have all that information, it's too late (at least for OpenSIPS) to do anything about it. It'd have to be dealt within MediaProxy. It's the simplest way I found to be able to decide to use transcoding or not on the fly. What do you think of this approach ? I agree it's complicated but re-INVITEs come with their own issues in heterogeneous environments. I still don't understand how would you put the transcoding card 'in the middle'. And also, the SDP must be fixed, because endpoints will need to know in what codec they are talking. This last thing could be faked by always adding G729 to the offer and answer, but I've seen some devices fail if they get more than one codec as an answer. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
