[OpenSIPS-Users] RTPPROXY and forked INVITE: bug in opensips or bug in config?

[Nick Altmann]

I do it in the main route. Dump sent via private mail.

--
Nick

2012/7/16 Bogdan-Andrei Iancu <bogdan at opensips.org>

> **
> Maybe you are doing the RTPproxy stuff in branch route ? If not, could you
> post a SIP capture showing the incoming INVITE and the outgoing INVITEs ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 07/16/2012 12:07 PM, Nick Altmann wrote:
>
> Yes, it is.
>
> --
> Nick
>
> 2012/7/16 Bogdan-Andrei Iancu <bogdan at opensips.org>
>
>>  Hi Nick,
>>
>> So, what you say is when doing parallel forking (based on usrloc) and
>> when in request route, before relay, you do rtpproxy_offer(), you get
>> changed only the INVITE for the first branch ?
>>
>> Regards,
>> Bogdan
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>> On 07/16/2012 11:11 AM, Nick Altmann wrote:
>>
>>  Hello!
>>
>>  I call rtpproxy_offer("cof") before t_relay in my config. When INVITE
>> passes through this rules, I see ip address of my rtpproxy in SDP. It's
>> okay.
>>
>>  Another situation:
>> Client registered on opensips and have _two_ registrations with the same
>> name.
>> So, when I do t_relay of INVITE, it forks to _two_ INVITES. It's also
>> okay.
>>
>>  Before t_relay, I also call rtpproxy_offer("cof").
>>
>>  But why in the first INVITE I see the ip address of my rtpproxy, but in
>> the second INVITE I see original (source) ip address in SDP?
>>
>>  --
>> Nick
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120716/4a6e4a27/attachment.htm>