Proxy Media and Codec Prefer
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3 FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080"/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080"/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1) It's bug or not ? Dome C.
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg. So it's expected behaviour. -Steve On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080"/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080"/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thank you for the explanation Steven. However, if we see that there is a common codec, say G729, and we want to make sure that the call gets connected on G729, is there any way to enforce this? Regards HASSAN On Mon, Aug 2, 2010 at 12:44, Steven Ayre <steveayre@gmail.com> wrote:
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg.
So it's expected behaviour.
-Steve
On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080 "/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080 "/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yes, don't use proxy media. Use absolute_codec_string as you already were to enforce it. There is no way if you're using proxy media. -Steve On 2 August 2010 08:23, Nyamul Hassan <mnhassan@usa.net> wrote:
Thank you for the explanation Steven. However, if we see that there is a common codec, say G729, and we want to make sure that the call gets connected on G729, is there any way to enforce this?
Regards HASSAN
On Mon, Aug 2, 2010 at 12:44, Steven Ayre <steveayre@gmail.com> wrote:
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg.
So it's expected behaviour.
-Steve
On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080 "/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080 "/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Interesting. In proxy media, FS is in the middle of the media transfer, and one would think that such was possible in such situations. In contrast, when you are not acting as a media proxy, there is little on what media the end points can negotiate among themselves. There must be some logical reasoning that I fail to understand here. Regards HASSAN On Mon, Aug 2, 2010 at 14:01, Steven Ayre <steveayre@gmail.com> wrote:
Yes, don't use proxy media. Use absolute_codec_string as you already were to enforce it.
There is no way if you're using proxy media.
-Steve
On 2 August 2010 08:23, Nyamul Hassan <mnhassan@usa.net> wrote:
Thank you for the explanation Steven. However, if we see that there is a common codec, say G729, and we want to make sure that the call gets connected on G729, is there any way to enforce this?
Regards HASSAN
On Mon, Aug 2, 2010 at 12:44, Steven Ayre <steveayre@gmail.com> wrote:
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg.
So it's expected behaviour.
-Steve
On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080 "/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080 "/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FS has 3 ways (not 2!) to handle media: 1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored. On Monday 02 August 2010, Nyamul Hassan wrote:
Interesting. In proxy media, FS is in the middle of the media transfer, and one would think that such was possible in such situations.
In contrast, when you are not acting as a media proxy, there is little on what media the end points can negotiate among themselves.
There must be some logical reasoning that I fail to understand here.
Regards HASSAN
On Mon, Aug 2, 2010 at 14:01, Steven Ayre <steveayre@gmail.com> wrote:
Yes, don't use proxy media. Use absolute_codec_string as you already were to enforce it.
There is no way if you're using proxy media.
-Steve
On 2 August 2010 08:23, Nyamul Hassan <mnhassan@usa.net> wrote:
Thank you for the explanation Steven. However, if we see that there is a common codec, say G729, and we want to make sure that the call gets connected on G729, is there any way to enforce this?
Regards HASSAN
On Mon, Aug 2, 2010 at 12:44, Steven Ayre <steveayre@gmail.com> wrote:
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg.
So it's expected behaviour.
-Steve
On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:508 0 "/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:508 0 "/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-user s http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear. On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT. On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
http://wiki.freeswitch.org/wiki/Codec_negotiation disable-transcoding On Aug 15, 2010, at 8:07 PM, Sergey Okhapkin wrote:
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT.
On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
But what if endpoints have no common codec and disable-transcoding is set? Will FS ignore disable-transcoding parameter? On Sunday 15 August 2010, Michael Jerris wrote:
http://wiki.freeswitch.org/wiki/Codec_negotiation
disable-transcoding
On Aug 15, 2010, at 8:07 PM, Sergey Okhapkin wrote:
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT.
On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Proxy media does not handle this case now and the call will fail in the same way. We will try to avoid transcoding by default, so I think what you are suggesting is already the default action without proxy_media. On Aug 15, 2010, at 8:48 PM, Sergey Okhapkin wrote:
But what if endpoints have no common codec and disable-transcoding is set? Will FS ignore disable-transcoding parameter?
On Sunday 15 August 2010, Michael Jerris wrote:
http://wiki.freeswitch.org/wiki/Codec_negotiation
disable-transcoding
On Aug 15, 2010, at 8:07 PM, Sergey Okhapkin wrote:
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT.
On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
Sure? How FS behaves now if disable-transcoding is set, late negotiation is on and proxy_media is not set? Will it forward packets as is if there are common codecs and fall back to transcoding if there are no common codecs on a and b leg? If this is current behavior, then I will definitely use it... On Sunday 15 August 2010, Michael Jerris wrote:
Proxy media does not handle this case now and the call will fail in the same way. We will try to avoid transcoding by default, so I think what you are suggesting is already the default action without proxy_media.
On Aug 15, 2010, at 8:48 PM, Sergey Okhapkin wrote:
But what if endpoints have no common codec and disable-transcoding is set? Will FS ignore disable-transcoding parameter?
On Sunday 15 August 2010, Michael Jerris wrote:
http://wiki.freeswitch.org/wiki/Codec_negotiation
disable-transcoding
On Aug 15, 2010, at 8:07 PM, Sergey Okhapkin wrote:
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT.
On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Just set late negotiation and it should do what you want. If you set disable-transcoding it will … disable transcoding, failing the call if no common codecs. On Aug 15, 2010, at 10:15 PM, Sergey Okhapkin wrote:
Sure? How FS behaves now if disable-transcoding is set, late negotiation is on and proxy_media is not set? Will it forward packets as is if there are common codecs and fall back to transcoding if there are no common codecs on a and b leg? If this is current behavior, then I will definitely use it...
On Sunday 15 August 2010, Michael Jerris wrote:
Proxy media does not handle this case now and the call will fail in the same way. We will try to avoid transcoding by default, so I think what you are suggesting is already the default action without proxy_media.
On Aug 15, 2010, at 8:48 PM, Sergey Okhapkin wrote:
But what if endpoints have no common codec and disable-transcoding is set? Will FS ignore disable-transcoding parameter?
On Sunday 15 August 2010, Michael Jerris wrote:
http://wiki.freeswitch.org/wiki/Codec_negotiation
disable-transcoding
On Aug 15, 2010, at 8:07 PM, Sergey Okhapkin wrote:
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT.
On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
Michael: Since what version does this become a default behavior? I was using 1.0.5 and I had to use proxy_media=true for the A -> FS -> B to avoid g729 codec priority issue. Let me explain: A has codec priority as g711, g729 FS has codec priority as g711, g729(passthrough) B has codec priority as g729 , then whatever esle *Without* proxy media= true: 1. A will negotiate with FS about which codec to use, since they both have g711 as the first priority, they will agree on using g711 to communicate. 2. Now FS will negotiate codec with B, and since B has g729 as priority, and FS has g729(passthrough) available, they will agree on using g729 as the codec. 3. Now the calls will bridge and drop right away since FS does not do codec translation. With proxy media = true 1. A will skip FS and negotiate codec with B directly. And they will use whatever matches they can find, and this will leave FS not worrying about codec translation at all. please correct me if the above scenario has been changed in the newer FS. Thanks, Henry Huang Unified Communication System R&D Project Manager US: +1 (626) 606-3306 Chat Skype: unicsolution MSN: b_ball_henry@hotmail.com Contact Me [image: Linkedin]<http://www.linkedin.com/pub/henry-huang/1/654/578>[image: Facebook] <http://www.facebook.com/profile.php?id=595148342>[image: Twitter]<http://twitter.com/unicsolution> On Mon, Aug 16, 2010 at 9:53 AM, Michael Jerris <mike@jerris.com> wrote:
Proxy media does not handle this case now and the call will fail in the same way. We will try to avoid transcoding by default, so I think what you are suggesting is already the default action without proxy_media.
On Aug 15, 2010, at 8:48 PM, Sergey Okhapkin wrote:
But what if endpoints have no common codec and disable-transcoding is set? Will FS ignore disable-transcoding parameter?
On Sunday 15 August 2010, Michael Jerris wrote:
http://wiki.freeswitch.org/wiki/Codec_negotiation
disable-transcoding
On Aug 15, 2010, at 8:07 PM, Sergey Okhapkin wrote:
To avoid transcoding if both endpoints have common codec, but one of endpoints is behind NAT.
On Sunday 15 August 2010, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
On Aug 2, 2010, at 6:25 AM, Sergey Okhapkin wrote:
FS has 3 ways (not 2!) to handle media:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode. 2. proxy_media=true - media is proxied by FS, but without any transcoding etc, frame in - frame out. absolute_codec_string variable is ignored in this mode. 3. Neither bypass_media, no proxy_media variables are set. FS does full media handling/transcoding, absolute_codec_string variable is honored.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Feel free to confirm for yourself, check out latest git and report back to all. On Aug 16, 2010, at 2:00 AM, Henry Huang wrote:
Michael:
Since what version does this become a default behavior? I was using 1.0.5 and I had to use proxy_media=true for the A -> FS -> B to avoid g729 codec priority issue. Let me explain: A has codec priority as g711, g729 FS has codec priority as g711, g729(passthrough) B has codec priority as g729 , then whatever esle
Without proxy media= true: 1. A will negotiate with FS about which codec to use, since they both have g711 as the first priority, they will agree on using g711 to communicate. 2. Now FS will negotiate codec with B, and since B has g729 as priority, and FS has g729(passthrough) available, they will agree on using g729 as the codec. 3. Now the calls will bridge and drop right away since FS does not do codec translation.
With proxy media = true 1. A will skip FS and negotiate codec with B directly. And they will use whatever matches they can find, and this will leave FS not worrying about codec translation at all.
please correct me if the above scenario has been changed in the newer FS.
I use proxy_media as a default because i use only mobile clients. In mobile networks there are good chance that FS NAT detection does not work. That's because several mobile carriers use as "internal ip address" IP that are not inside the standard 192.168/16 10/8 and 172.16/16 networks. For example H3G in italy use 1/8 networks and in other countries there are other fancy approach that are unpredictable. In such condition proxy_media is the only solution to have a 100% working solution, otherwise in a X% of the case on some mobile operator it will just don't work. And following all the "particular" internal networks that mobile operators follow is not a good way to manage the issue as there are too many mobile operators in the world and too many different internal network conditions. It would be really nice to have some kind of "dynamic" approach, like the ones provided by ICE, that are client-independent and server-side based to handle such particular issues (IE: without the ability to rely on client IP address being inside a particular network). Fabio On 16/08/10 01.56, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
This is a case of your nat settings simply not being right on the FreeSWITCH side I suspect, study the acl settings and come up with an example of a failure here with full sip trace and debug. Mike On Aug 16, 2010, at 4:39 AM, Fabio Pietrosanti (naif) wrote:
I use proxy_media as a default because i use only mobile clients.
In mobile networks there are good chance that FS NAT detection does not work.
That's because several mobile carriers use as "internal ip address" IP that are not inside the standard 192.168/16 10/8 and 172.16/16 networks.
For example H3G in italy use 1/8 networks and in other countries there are other fancy approach that are unpredictable. In such condition proxy_media is the only solution to have a 100% working solution, otherwise in a X% of the case on some mobile operator it will just don't work.
And following all the "particular" internal networks that mobile operators follow is not a good way to manage the issue as there are too many mobile operators in the world and too many different internal network conditions.
It would be really nice to have some kind of "dynamic" approach, like the ones provided by ICE, that are client-independent and server-side based to handle such particular issues (IE: without the ability to rely on client IP address being inside a particular network).
Fabio
On 16/08/10 01.56, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
http://pastebin.freeswitch.org/13643 , note lines 185 (SDP from B leg, 3 codecs) and 260 (SDP sent to A leg, only 1 codec). The call is running with bypass_media=true. On Monday 16 August 2010, Michael Jerris wrote:
This is a case of your nat settings simply not being right on the FreeSWITCH side I suspect, study the acl settings and come up with an example of a failure here with full sip trace and debug.
Mike
On Aug 16, 2010, at 4:39 AM, Fabio Pietrosanti (naif) wrote:
I use proxy_media as a default because i use only mobile clients.
In mobile networks there are good chance that FS NAT detection does not work.
That's because several mobile carriers use as "internal ip address" IP that are not inside the standard 192.168/16 10/8 and 172.16/16 networks.
For example H3G in italy use 1/8 networks and in other countries there are other fancy approach that are unpredictable. In such condition proxy_media is the only solution to have a 100% working solution, otherwise in a X% of the case on some mobile operator it will just don't work.
And following all the "particular" internal networks that mobile operators follow is not a good way to manage the issue as there are too many mobile operators in the world and too many different internal network conditions.
It would be really nice to have some kind of "dynamic" approach, like the ones provided by ICE, that are client-independent and server-side based to handle such particular issues (IE: without the ability to rely on client IP address being inside a particular network).
Fabio
On 16/08/10 01.56, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
In bypass media we pass the sdp through directly. I am unsure what you are trying to show me here and what it has to do with the problem you describe. Mike On Aug 16, 2010, at 10:02 AM, Sergey Okhapkin wrote:
http://pastebin.freeswitch.org/13643 , note lines 185 (SDP from B leg, 3 codecs) and 260 (SDP sent to A leg, only 1 codec). The call is running with bypass_media=true.
On Monday 16 August 2010, Michael Jerris wrote:
This is a case of your nat settings simply not being right on the FreeSWITCH side I suspect, study the acl settings and come up with an example of a failure here with full sip trace and debug.
Mike
On Aug 16, 2010, at 4:39 AM, Fabio Pietrosanti (naif) wrote:
I use proxy_media as a default because i use only mobile clients.
In mobile networks there are good chance that FS NAT detection does not work.
That's because several mobile carriers use as "internal ip address" IP that are not inside the standard 192.168/16 10/8 and 172.16/16 networks.
For example H3G in italy use 1/8 networks and in other countries there are other fancy approach that are unpredictable. In such condition proxy_media is the only solution to have a 100% working solution, otherwise in a X% of the case on some mobile operator it will just don't work.
And following all the "particular" internal networks that mobile operators follow is not a good way to manage the issue as there are too many mobile operators in the world and too many different internal network conditions.
It would be really nice to have some kind of "dynamic" approach, like the ones provided by ICE, that are client-independent and server-side based to handle such particular issues (IE: without the ability to rely on client IP address being inside a particular network).
Fabio
On 16/08/10 01.56, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yes, it's supposed to be passed directly (and it is passed directly on 200 OK), but only 1st codec is passed to leg A on SIP 183! On Monday 16 August 2010, Michael Jerris wrote:
In bypass media we pass the sdp through directly. I am unsure what you are trying to show me here and what it has to do with the problem you describe.
Mike
On Aug 16, 2010, at 10:02 AM, Sergey Okhapkin wrote:
http://pastebin.freeswitch.org/13643 , note lines 185 (SDP from B leg, 3 codecs) and 260 (SDP sent to A leg, only 1 codec). The call is running with bypass_media=true.
On Monday 16 August 2010, Michael Jerris wrote:
This is a case of your nat settings simply not being right on the FreeSWITCH side I suspect, study the acl settings and come up with an example of a failure here with full sip trace and debug.
Mike
On Aug 16, 2010, at 4:39 AM, Fabio Pietrosanti (naif) wrote:
I use proxy_media as a default because i use only mobile clients.
In mobile networks there are good chance that FS NAT detection does not work.
That's because several mobile carriers use as "internal ip address" IP that are not inside the standard 192.168/16 10/8 and 172.16/16 networks.
For example H3G in italy use 1/8 networks and in other countries there are other fancy approach that are unpredictable. In such condition proxy_media is the only solution to have a 100% working solution, otherwise in a X% of the case on some mobile operator it will just don't work.
And following all the "particular" internal networks that mobile operators follow is not a good way to manage the issue as there are too many mobile operators in the world and too many different internal network conditions.
It would be really nice to have some kind of "dynamic" approach, like the ones provided by ICE, that are client-independent and server-side based to handle such particular issues (IE: without the ability to rely on client IP address being inside a particular network).
Fabio
On 16/08/10 01.56, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Who sends the 183? the far side? And please limit your issue to ONE thread on the list not two please. I still haven't seen a full console log with sip trace. /b On Aug 16, 2010, at 10:12 AM, Sergey Okhapkin wrote:
Yes, it's supposed to be passed directly (and it is passed directly on 200 OK), but only 1st codec is passed to leg A on SIP 183!
On Monday 16 August 2010, Michael Jerris wrote:
In bypass media we pass the sdp through directly. I am unsure what you are trying to show me here and what it has to do with the problem you describe.
Mike
The log is on pastebin. You're correct, 183 comes from far side, from called PSTN gateway on leg B. On Monday 16 August 2010, Brian West wrote:
Who sends the 183? the far side? And please limit your issue to ONE thread on the list not two please. I still haven't seen a full console log with sip trace.
/b
On Aug 16, 2010, at 10:12 AM, Sergey Okhapkin wrote:
Yes, it's supposed to be passed directly (and it is passed directly on 200 OK), but only 1st codec is passed to leg A on SIP 183!
On Monday 16 August 2010, Michael Jerris wrote:
In bypass media we pass the sdp through directly. I am unsure what you are trying to show me here and what it has to do with the problem you describe.
Mike
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I wonder why the last line in the log says skipping state [early][183] for leg A? Code in sofia.c do not copy SDP in this case. On Monday 16 August 2010, Sergey Okhapkin wrote:
Yes, it's supposed to be passed directly (and it is passed directly on 200 OK), but only 1st codec is passed to leg A on SIP 183!
On Monday 16 August 2010, Michael Jerris wrote:
In bypass media we pass the sdp through directly. I am unsure what you are trying to show me here and what it has to do with the problem you describe.
Mike
On Aug 16, 2010, at 10:02 AM, Sergey Okhapkin wrote:
http://pastebin.freeswitch.org/13643 , note lines 185 (SDP from B leg, 3 codecs) and 260 (SDP sent to A leg, only 1 codec). The call is running with bypass_media=true.
On Monday 16 August 2010, Michael Jerris wrote:
This is a case of your nat settings simply not being right on the FreeSWITCH side I suspect, study the acl settings and come up with an example of a failure here with full sip trace and debug.
Mike
On Aug 16, 2010, at 4:39 AM, Fabio Pietrosanti (naif) wrote:
I use proxy_media as a default because i use only mobile clients.
In mobile networks there are good chance that FS NAT detection does not work.
That's because several mobile carriers use as "internal ip address" IP that are not inside the standard 192.168/16 10/8 and 172.16/16 networks.
For example H3G in italy use 1/8 networks and in other countries there are other fancy approach that are unpredictable. In such condition proxy_media is the only solution to have a 100% working solution, otherwise in a X% of the case on some mobile operator it will just don't work.
And following all the "particular" internal networks that mobile operators follow is not a good way to manage the issue as there are too many mobile operators in the world and too many different internal network conditions.
It would be really nice to have some kind of "dynamic" approach, like the ones provided by ICE, that are client-independent and server-side based to handle such particular issues (IE: without the ability to rely on client IP address being inside a particular network).
Fabio
On 16/08/10 01.56, Michael Jerris wrote:
I don't think there is ever a reason to use proxy_media anymore. If anyone can provide an example of a good reason to use it I would be interested to hear.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-user s http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
My preference is to use this bypass_media=true option to relief FS from proxying the media. This has some drawbacks, i.e. MOH won't work, etc. Sergey Okhapkin wrote:
1. bypass_media=true - media path is set to run audio directly between leg a and b endpoints. absolute_codec_string variable is ignored in this mode.
----- don't and stop are the ONLY two 4-letter words considered offensive to men, but not when used together. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Proxy-Media-and-Codec-Prefer-t... Sent from the freeswitch-users mailing list archive at Nabble.com.
Currently, I included bypass_media=true to every dialplan file, but prefer to make it a default setting. So, which file should I edit to include bypass_media=true as a default setting for the whole FS system? ----- don't and stop are the ONLY two 4-letter words considered offensive to men, but not when used together. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Proxy-Media-and-Codec-Prefer-t... Sent from the freeswitch-users mailing list archive at Nabble.com.
When neitther bypass media nor proxy media is set, FS still is in the media path. The difference between 'normal' and 'proxy' is that FS doesn't do anything with the media, just passes it straight through. You seem to be thinking that bypass media is the default - it isn't. -Steve On 2 August 2010 09:40, Nyamul Hassan <mnhassan@usa.net> wrote:
Interesting. In proxy media, FS is in the middle of the media transfer, and one would think that such was possible in such situations.
In contrast, when you are not acting as a media proxy, there is little on what media the end points can negotiate among themselves.
There must be some logical reasoning that I fail to understand here.
Regards HASSAN
On Mon, Aug 2, 2010 at 14:01, Steven Ayre <steveayre@gmail.com> wrote:
Yes, don't use proxy media. Use absolute_codec_string as you already were to enforce it.
There is no way if you're using proxy media.
-Steve
On 2 August 2010 08:23, Nyamul Hassan <mnhassan@usa.net> wrote:
Thank you for the explanation Steven. However, if we see that there is a common codec, say G729, and we want to make sure that the call gets connected on G729, is there any way to enforce this?
Regards HASSAN
On Mon, Aug 2, 2010 at 12:44, Steven Ayre <steveayre@gmail.com> wrote:
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg.
So it's expected behaviour.
-Steve
On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/ 2222@10.20.2.49:5080"/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge" data="{absolute_codec_string='G729'}sofia/internal/ 2222@10.20.2.49:5080"/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
<action application="set" data="proxy_media=true"/> Use when leg A and Leg B use same codec but need to proxy Right ? Dome C. 2010/8/2 Steven Ayre <steveayre@gmail.com>:
Yes, don't use proxy media. Use absolute_codec_string as you already were to enforce it.
There is no way if you're using proxy media.
-Steve
On 2 August 2010 08:23, Nyamul Hassan <mnhassan@usa.net> wrote:
Thank you for the explanation Steven. However, if we see that there is a common codec, say G729, and we want to make sure that the call gets connected on G729, is there any way to enforce this? Regards HASSAN
On Mon, Aug 2, 2010 at 12:44, Steven Ayre <steveayre@gmail.com> wrote:
In proxy media mode FS will pass media straight through without any processing. It won't do any transcoding or any SDP modifcation, so it can't transcode PCMU <-> G729 and absolute_codec_string will be ignored - it'll just pass the codec settings straight through from the A leg to the B leg.
So it's expected behaviour.
-Steve
On 2 August 2010 04:55, Dome Charoenyost <dome@tel.co.th> wrote:
Dear All, I'm not sure it's bug or not ? I try to test codec negotate. with 3 FS box FS1 send PCMA to FS2 and FS2 send G729 to FS3
FS1 -----> [PCMU] ----> FS2 ------> [G729] -------> FS3 (10.20.2.49) My dialplan <action application="bridge"
data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080"/> It's work fine When i try <action application="set" data="proxy_media=true"/> <action application="bridge"
data="{absolute_codec_string='G729'}sofia/internal/2222@10.20.2.49:5080"/> Call fail. because FS2 ignore absolute_codec_string='G729' and send only PCMU (I think by pass from FS1)
It's bug or not ?
Dome C.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (9)
-
Brian West
-
Dome Charoenyost
-
Fabio Pietrosanti (naif)
-
Henry Huang
-
mazilo
-
Michael Jerris
-
Nyamul Hassan
-
Sergey Okhapkin
-
Steven Ayre