[asterisk-users] PJSIP Stun/ICE

[Bryant Zimmerman]

Joshua
  
 I look forward to improvements as time goes on with PJSIP.
 I have been trying all day to get the Transport objects to pull from a 
real-time table. The documentation says it is possible, but does not show 
any examples. I am hoping to have the Transports pulled from the table at 
asterisk startup and then add additional as necessary. Using reloads to 
make the new Transports available. I understand the limitation of not being 
able to change existing and can live with that for now.   
  
 Do you know if there is anything special I have to do in the sorcery.conf 
to make the Transports pull from the real-time side of things. All my other 
tables are working.
  
 I disagree with the user that things PJSIP is worthless. There are some 
issues to work out long term, and documentation will get better over time 
as more of us work with it and contribute back.  Thanks for all you have 
assisted with around PJSIP.
  
 Bryant 

----------------------------------------
 From: "Joshua Colp" <jcolp at digium.com>
Sent: Tuesday, January 26, 2016 8:40 PM
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
<asterisk-users at lists.digium.com>
Subject: Re: [asterisk-users] PJSIP Stun/ICE   
James Cloos wrote:
>>>>>> "JC" == Joshua Colp<jcolp at digium.com> writes:
>
> JC> This stems from PJSIP not being dynamic with transports (it
> JC> doesn't like its environment changed to that degree while
> JC> in use). I'm afraid if your IP changes you'd have to restart
> JC> Asterisk when you are using PJSIP.
>
> Wow.
>
> I say this having voted for pjsip over the listed alternatives back when
> the plan to depricate chan_sip was first floated:
>
> That should have excluded pj from the options. Which of course means
> there were no reasonable options.

PJSIP doesn't like changing existing transports, the NAT functionality
is provided by the Asterisk implementation and can't be reloaded as a
side effect due to the heavy handed restriction. With work it could be
changed to allow the non low level things to be changed. What you can't
do with PJSIP is create a UDP transport, reload, and have it removed.
Once it's there it is there unless you restart.

>
> Can ari get around that bug?

ARI is a REST interface to Asterisk, it doesn't have anything to do with
this.

>
> Lack of full support for traversing nat makes pjsip worthless for a
> large number of users. And the whole point of realtime is to have all
> of the rt config fully dymanic.

I disagree that it makes it worthless for a large number of users. It's
only within the last few days that a few people have run into this
particular issue where they have a public IP address that is changing a
lot and PJSIP does not support changing it without a restart. If it were
a huge sweeping issue we'd be seeing it more often. If it continues to
show up a community member or us (heck maybe even myself in my spare
time) may look into implementing it.

>
> If ari cannot avoid that limitation, chan_sip should get full ongoing
> maintainance until pjsip is fixed.

The support level for chan_sip has already been changed and was
announced long ago. Patches will continue to be accepted for it and
community members can support it. We (Digium) are putting our effort
towards PJSIP.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160126/00a39f5d/attachment.html>