Hi Hitesh,
when STUN is enabled, current pjsip will work best if you use a
(public) SIP server to route requests between clients, since pjsip
will take care of maintaining the connection to the proxy server
(keeping the NAT binding open, taking care of NAT binding change,
etc.). This way you'll be able to route requests to any clients no
matter where they are located (either on different public network,
or on the same LAN).
But if you want to use private IP as you SIP address, that's also
possible, but we'll need to use different approach. The problem with
your approach is it's interacting with intimate details of pjsip, so
it's not guaranteed to work in the future. A better approach is to
specify your (private) IP address in the "public_addr" field of
pjsua_transport_config, to tell pjsip to use this value instead of
resolving the address with STUN. This technique will only work with
0.8.0 though.
HTH,
-benny
logan wrote:
> Hello,
>
> I wanted to have two accounts registered with PJSIP, one was local and other
> on the public internet. Thus, I needed STUN and ICE. However, with enabling
> them, my local account would register with the STUN mapped IP and when
> someone on the same local network tried calling me up then the INVITE never
> reached me as it was send on the global IP.
>
> Following are some code snippet with the comments explaining the intent:
>
> //We would need this to modify the pjsua_var structure
> #include "pjsua-internal.h"
> ...
> //Set the STUN server
> cfg.stun_host = pj_str ("stun.fwdnet.net);
> //Enable ICE and other stuff
> ...
> pjsua_init (&cfg, &log_cfg, &media_cfg);
>
> //We create two transports now, one will be used with the local account and
> other
> //with the STUN and ICE enabled
>
> pjsua_transport_config local_transport_cfg; //For local account
> pjsua_transport_config default_transport_cfg; //For the one on public
> Internet
>
> pjsua_transport_config_default (&local_transport_cfg);
> pjsua_transport_config_default (&default_transport_cfg);
>
> //Set up RTP transport, ports, etc
>
> //Create the default transport
> pjsua_transport_create (PJSIP_TRANSPORT_UDP,
> &default_transport_cfg,
> &default_transport_id);
>
> //Uptil now we didn't do anything special
>
> //Force the STUN address to be NULL so that it creates a transport without
> using STUN
> pjsua_var.ua_cfg.stun_host = pj_str ("");
> //Set STUN status to be unknown
> pjsua_var.stun_status = PJ_EUNKNOWN;
>
> //Create transport to be used with local account
> ret = pjsua_transport_create (PJSIP_TRANSPORT_UDP,
> &local_transport_cfg,
> &local_transport_id);
>
> //We created the transport for local account but we need STUN as well so
> //we set them back
>
> //Set back the STUN server
> pjsua_var.ua_cfg.stun_host = pj_str ("stun.fwdnet.net");
> //Set STUN status to be unknown
> pjsua_var.stun_status = PJ_EUNKNOWN;
>
> //Once again resolve the STUN server address
> pjsua_resolve_stun_server (PJ_FALSE);
>
> //And while adding accounts I force the account to use
> //local or default transport with pjsua_acc_config::transport_id
>
> //In pjsua_resolve_stun_server I added the following *hack*
> //Line no: 849
>
> /* Otherwise disable STUN. */
>
> else {
>
> pjsua_var.stun_srv.addr.sa_family = 0;
> //Added by logan
> pjsua_var.stun_status = PJ_SUCCESS;
>
> }
>
> That's all and it serves me just fine. Benny, are there any caveats with
> this approach?
>
> In your case, what I guess you can do is, create a local transport and when
> you know that the calling party is on the same network then make your
> account use the local transport through:
>
> pjsua_var.acc[acc_id].cfg.transport_id = local_transport_id;
>
> I have not tried it, but it might work because pjsua_make_call checks for
> the transport ID to use before sending any messages. I hope it helps.
>
> Thanks.
>
> Best Regards,
> Hitesh
>
>
> ----- Original Message -----
> From: "Michael Bradley Jr" <mbradley.jr@xxxxxxxxx>
> To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org>
> Sent: Friday, November 09, 2007 7:50 PM
> Subject: Re: STUN & local call
>
>
>> Hi Logan,
>>
>> yes the purpose is a B2B call.
>> Can you provide the asked hint ;)
>> Cheers
>> Mike
>>
>> logan wrote:
>>> Hi,
>>>
>>> Your case is not clear to me, are you trying to make B2B SIP calls? Or
>>> your proxy is local but with STUN being enabled you are having
>>> problems?
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>> Hitesh
>>>
>>> On Nov 4, 2007 5:24 PM, Benny Prijono <bennylp at pjsip.org> wrote:
>>>> Michael Bradley Jr wrote:
>>>>> Hi,
>>>>>
>>>>> when STUN is enable, i can't make a successful call to an UA in the
>>>>> same Network
>>>>> segment.
>>>>>
>>>>> Here is call flow
>>>>>
>>>>> UA1: pjsua 0.7.0
>>>>> localIP: 192.168.0.23 publicIP: 88.xx.xx.xx
>>>>>
>>>>> UA2: Grandstream IP-Phone
>>>>> localIP: 192.168.0.32 publicIP: 88.xx.xx.xx
>>>>>
>>>>>
>>>>> UA1 ---> UA2 (192.168.0.23 >> 192.168.0.32)
>>>>> INVITE sip:xvc at 192.168.0.32 SIP/2.0
>>>>> sdp: c:88.xx.xx.xx
>>>>>
>>>>> UA2 --> UA1 (192.168.0.32 --> 88.xx.xx.xx)
>>>>> 200/2.0/UDP 88.xx.xx.xx:5060
>>>>> sdp: c: 192.168.0.32
>>>>>
>>>>>
>>>>> UA1 never get the 200 since it's send to the public Address...
>>>>>
>>>>> So my question:
>>>>> how can i set the IP of the destination of the RTP stream in my initial
>>>>> INVITE using pjsua-lib since i can figure out that both UA are behind
>>>>> the same NAT?
>>>> Currently you can't. When STUN is used, the public IP will always be
>>>> used in the SDP, regardless of where the destination UA is located.
>>>> But if only the other UA (UA2) is also pjsua, then there shouldn't
>>>> be any problem with media communication since pjsua will switch the
>>>> destination RTP/RTCP address to the source address of the packet.
>>>>
>>>> And when you use pjsua to pjsua, you can enable ICE as well. With
>>>> ICE enabled, it will automatically select which media address to use
>>>> based on ICE negotiation.
>>>>
>>>> cheers,
>>>> -benny
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Michael
