[OpenSIPS-Users] rtp_proxy_stream2uac and opensips-1.6.4

[Kamen Petrov]

Flavio:

http://en.wikipedia.org/wiki/G.729
<http://en.wikipedia.org/wiki/G.729>"G.729 includes
patents<http://en.wikipedia.org/wiki/Software_patent> from
several companies and is licensed by Sipro Lab Telecom. "

http://en.wikipedia.org/wiki/GSM#Voice_codecs
 <http://en.wikipedia.org/wiki/GSM#Voice_codecs>I think, patent issues here
too.

*
Thanks
-- Kamen*


On 11 March 2011 16:41, Flavio Goncalves <flavio at asteriskguide.com> wrote:

> Razvan,
>
> I need to implement this feature with GSM and G729, but I see that this
> files do not appear in the rtpproxy distribution. Any tip?
>
> Best regards,
>
> Flavio E. Goncalves
>
>
>
>
> 2011/3/11 Razvan Crainea <razvancrainea at opensips.org>
>
>>  Hello Flavio,
>>
>> I don't know why you have to take the check out. Probably this is a little
>> bug. I will dig into this and let you know as soon as I solve the problem.
>>
>> Regards,
>> Razvan
>>
>>
>> On 03/11/2011 04:35 PM, Flavio Goncalves wrote:
>>
>> Hi Razvan,
>>
>>  I got to make it work using a version downloaded from GIT. There was a
>> mistake in the name of the file, it is working, I have removed the check
>> from rtpproxy_stream.c
>>
>>  Thanks for helping.
>>
>> Flavio E. Goncalves
>>
>>
>>
>>
>> 2011/3/11 Razvan Crainea <razvancrainea at opensips.org>
>>
>>>  Hi Flavio,
>>>
>>> Can you please give me the output of the command "rtpproxy -v"?
>>>
>>> The word "session" specifies RTPProxy to search for the codec list in the
>>> initial Update command (when OpenSIPS calls rtpproxy_offer), so there is
>>> nothing wrong with it.
>>>
>>> This is how RTPProxy works when it receives a Play command:
>>> Assuming your initial codec list is "3,8,101", your command is
>>> interpreted like this:
>>> it checks in the '/var/rtpproxy/prompts/' folder for the 'dmcaller.3'
>>> file (which should be a GSM encoded file). If found, it starts to play it to
>>> the uac/uas. Otherwise it checks further for the 'dmcaller.8' file, and so
>>> on until it finds a suitable media file. If it doesn't, it should log an
>>> error.
>>> I guess your problem is that RTPProxy is unable to find a suitable file
>>> to open.
>>>
>>> Regards,
>>> Razvan
>>>
>>>
>>> On 03/11/2011 03:23 PM, Flavio Goncalves wrote:
>>>
>>>  Hi,
>>>
>>>  Is there anyone with experience using rtpproxy_stream2uac command. I'm
>>> trying to use with OpenSIPS 1.6.4 with rtpproxy-1.2.1. I'm getting the
>>> following error:
>>>
>>>  ERROR:nathelper:rtpproxy_stream: required functionality is not
>>> supported by the version of the RTPproxy running on the selected node.
>>>  Please upgrade the RTPproxy and try again.
>>>
>>>  1. I tried to upgrade the RTPPROXY with the on in GIT, but it crashes
>>> as soon as I start OpenSIPS.
>>>
>>>  2. I tried to disabe the check in the rtpproxy_stream2uac, I don't get
>>> the error but still don't work. In this case:
>>>
>>>  OpenSIPS is sending to the RTPPROXY
>>>
>>>  DBUG:handle_command: received command "23907_6 P10
>>> f765564a-317a422b at 192.168.1.175 /var/rtpproxy/prompts/dmcaller session
>>> 5cc2dfbec1d32747o2;1 as1dc4b372;1"
>>>
>>>  The RTPPROXY is expecting according to the RTPPROXY protocol
>>>
>>>  P[args] callid play_name codecs from_tag to_tag
>>>
>>>  The mismatch seems to be in the word "session" in this place rtpproxy
>>> is expecting the codecs.
>>>
>>>  I tried everything I could.
>>>
>>>  Flavio E. Goncalves
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110311/268b7db6/attachment-0001.htm>