[OpenSIPS-Devel] [ opensips-Feature Requests-3053420 ] $du is writable and $dd is not
Feature Requests item #3053420, was opened at 2010-08-26 11:40 Message generated for change (Tracker Item Submitted) made by cupotka2008 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3053420group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: None Status: Open Priority: 5 Private: No Submitted By: Alex Massover (cupotka2008) Assigned to: Nobody/Anonymous (nobody) Summary: $du is writable and $dd is not Initial Comment: Hi, Any reason why $dd (destination domain) is not writable while $du (destination URI) is? In analogy with $ru and $rd which both are writable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086413aid=3053420group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Presence Subscriptions from External Domains
Hello, I have a question maybe someone can help or comment. How can one protect in the real world against faking the identity of presence subscriptions originating from foreign domains? The scenario is: Once us...@domaina accepts presence subscriptions from us...@domainb and his pre-rules is updated with this information, nobody stops somebody else to impersonate us...@domainb to send subscribe messages from any source and presenting the same From header. How can the server that serves domainA check for the real identity of the foreign subscriber? Can anyone comment what would be a good practical solution? Regards, Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Presence Subscriptions from External Domains
26 aug 2010 kl. 12.46 skrev Adrian Georgescu: Hello, I have a question maybe someone can help or comment. How can one protect in the real world against faking the identity of presence subscriptions originating from foreign domains? The scenario is: Once us...@domaina accepts presence subscriptions from us...@domainb and his pre-rules is updated with this information, nobody stops somebody else to impersonate us...@domainb to send subscribe messages from any source and presenting the same From header. How can the server that serves domainA check for the real identity of the foreign subscriber? Can anyone comment what would be a good practical solution? No, what you're talking about is trust between domains. SIP identity is trying to get a grip on that, as well as a few other identity solutions, including S/MIME in the good ol' RFC 3261. /O ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] media proxy with sangoma
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
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] [OpenSIPS-Users] Presence Subscriptions from External Domains
I remember that some opposed the use of this RFC when it came about telephone numbers because there is no domain part involved. For Presence I do not see telephone numbers involved but only SIP URIs. Would there be other issues against the use of this RFC for this very purpose? Adrian On Aug 26, 2010, at 1:34 PM, Olle E. Johansson wrote: 26 aug 2010 kl. 12.46 skrev Adrian Georgescu: Hello, I have a question maybe someone can help or comment. How can one protect in the real world against faking the identity of presence subscriptions originating from foreign domains? The scenario is: Once us...@domaina accepts presence subscriptions from us...@domainb and his pre-rules is updated with this information, nobody stops somebody else to impersonate us...@domainb to send subscribe messages from any source and presenting the same From header. How can the server that serves domainA check for the real identity of the foreign subscriber? Can anyone comment what would be a good practical solution? No, what you're talking about is trust between domains. SIP identity is trying to get a grip on that, as well as a few other identity solutions, including S/MIME in the good ol' RFC 3261. /O ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ 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
[OpenSIPS-Devel] SF.net SVN: opensips:[7160] trunk/modules/call_control
Revision: 7160 http://opensips.svn.sourceforge.net/opensips/?rev=7160view=rev Author: saghul Date: 2010-08-26 21:38:38 + (Thu, 26 Aug 2010) Log Message: --- Fixed small bug in Call Control documentation Reported by tompaw Modified Paths: -- trunk/modules/call_control/README trunk/modules/call_control/doc/call_control_admin.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7161] branches/1.6/modules/call_control
Revision: 7161 http://opensips.svn.sourceforge.net/opensips/?rev=7161view=rev Author: saghul Date: 2010-08-26 21:41:06 + (Thu, 26 Aug 2010) Log Message: --- Fixed small bug in Call Control documentation Reported by tompaw Modified Paths: -- branches/1.6/modules/call_control/README branches/1.6/modules/call_control/doc/call_control_admin.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[7162] branches/1.5/modules/call_control
Revision: 7162 http://opensips.svn.sourceforge.net/opensips/?rev=7162view=rev Author: saghul Date: 2010-08-26 21:43:15 + (Thu, 26 Aug 2010) Log Message: --- Fixed small bug in Call Control documentation Reported by tompaw Modified Paths: -- branches/1.5/modules/call_control/README branches/1.5/modules/call_control/doc/call_control_admin.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3047122 ] call_control doc bug
Bugs item #3047122, was opened at 2010-08-17 18:35 Message generated for change (Comment added) made by saghul You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3047122group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: docs Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: tompaw_tesserakt_eu (tompaw) Assigned to: saghul (saghul) Summary: call_control doc bug Initial Comment: URL: http://www.opensips.org/html/docs/modules/devel/call_control.html In section 1.5.6. diverter_avp_id, you're saying that: this AVP should contain a value in the form “u...@domain” (no sip: prefix should be used) However, in the following example, you have: $avp(i:805) = sip:al...@example.com; I think there should be no sip: in the value. -- Comment By: saghul (saghul) Date: 2010-08-26 23:49 Message: I just commited fixes for the documentation on trunk and branches 1.6 and 1.5 Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3047122group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
