Re: [reSIProcate-users] reSIP and reTurn
On Tue, Jul 22, 2008 at 2:35 PM, Chris Bick <bick.chris@xxxxxxxxx> wrote:
> The questions that is still lingering in my mind is if I have two peers(UA)
> behind a type of NAT that that allows communicating over UDP using RTP can I
> use reSIP to setup the "call" and then continue to use reSIP to transfer
> data between the two peers. I know this would work for two peers that were
> not behind a NAT and had a public IP.
[Scott] You would not use resip to transport RTP data - that is the
resip users/application's responsibility, and is done outside of the
stack. However you could transfer some other non-realtime arbitrary
data payload using SIP mechansims (ie. INFO/NOTIFY).
> If this is possible, and now knowing that reTurn can not be used in the
> "BasicCall" example, how would I modify the "BasicCall" example to use
> STUN? I found this page - http://www.resiprocate.org/STUN_support, and
> tried to use the sample code it provided, but from what I can tell the
> request to the STUN server is never made.
[Scott] Not sure what's going wrong here offhand.
> Thanks,
> -cb
>
>
> On 7/22/08, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
>>
>> Yeah that's correct. The recon project makes use of reTurn for
>> sending RTP via a TURN server, but it is not intergrated into
>> resiprocate for SIP messaging at this time. It is possible this will
>> get done sometime, but it not planned for anytime in the near future.
>>
>> In general if you have a SIP proxy on a public IP address and use this
>> for calling other registered users you should be able bypass any NAT
>> related issues - assuming the SIP client uses STUN to fix it's contact
>> address, or the registration is made over TCP and the SIP proxy
>> supports the outbound draft (ie. repro). Since RTP is P2P then use of
>> a TURN server may be required to relay RTP between the two users
>> behind NATs.
>>
>> Scott
>>
>> On Tue, Jul 22, 2008 at 12:00 PM, Karlsson <boost.regex@xxxxxxxxx> wrote:
>> > There is answer that Scott replied me a few days ago:
>> >
>> > reTurn is not currently implemented into the resiprocate stack - it
>> > would require a complete replacement of the resiprocate transport
>> > layer. It is currently primarily intended for use to transport media
>> > over a TURN allocation. If you need client side STUN support for DUM,
>> > then https://www.resiprocate.org/STUN_support is still the way to go.
>> >
>> >
>> > Hope this is helpful for you.
>> >
>> > More details need Scott answer you :)
>> >
>> > On Tue, Jul 22, 2008 at 11:06 PM, Chris Bick <bick.chris@xxxxxxxxx>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have a couple questions about the reSIP and reTurn projects. Some of
>> >> my
>> >> question my be better suited for the reTurn mailing list, but my
>> >> questions
>> >> focus on the integration between the two projects so I thought I would
>> >> start
>> >> with this mailing list.
>> >>
>> >> 1. Does the reSIP project currently use reTurn for NAT Traversal? I
>> >> noticed a couple calls on the UdpTransport object(stunSendTest,
>> >> stunResult)
>> >> for STUN support, but I don't think those calls are using reTurn.
>> >>
>> >> 2. If reSIP doesn't use reTurn are there plans to integrate them more
>> >> tightly in the future?
>> >>
>> >> 3. How would I modify the "BasicCall" example to use reTURN so the call
>> >> would work between two sip users behind a NAT?
>> >>
>> >>
>> >> Thanks,
>> >> -chris
>> >> _______________________________________________
>> >> resiprocate-users mailing list
>> >> resiprocate-users@xxxxxxxxxxxxxxx
>> >> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>> >
>> >
>> > _______________________________________________
>> > resiprocate-users mailing list
>> > resiprocate-users@xxxxxxxxxxxxxxx
>> > List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>> >
>
>