[asterisk-dev] Porting chan_sip patches res_pjsip

[Steve Murphy]

On Wed, Apr 12, 2017 at 3:30 PM, Joshua Colp <jcolp at digium.com> wrote:

> On Wed, Apr 12, 2017, at 05:53 PM, Steve Murphy wrote:
> > Hello, I must admit, as a beginner at this, that I have a lot to learn.
> >
> > I have written a module to handle some statistics gathering, and it works
> > fine,
> > but my next priority patch leaves me quite puzzled.
> >
> > If you or anyone will hear my situation, and offer possible solutions or
> > advice,
> > I would much appreciate the help.
> >
> > My next assignment is a patch that was made to chan_sip some years
> > back, that overcomes a problem with older aastra phones that are set up
> > to
> > turn functions keys into blf lights.
> >
> > Such a phone issues two registrations in quick succession. The first
> > indicates
> > a normal expire= time, and uses the correct CallerID. But the second
> > expiration
> > is presented with a different callerid, but the same sip device, and
> > gives
> > an
> > expires=0, which causes the phone to immediately deregister.
> >
>
> <snip>
>
> >
> > I have been studying the code, and have determined that the module in
> > res/res_pjsip_registrar would be proper spot to make the change, in the
> > registrar_validate_contacts function. I have but one small problem,
> > and that is, I need to access either the pjsip endpoint object, or the
> > asterisk object, to retrieve the expire value from the contact header of
> > the first
> > REGISTER request.
> >
> > It was easy in the chan_sip code: the peer held the expire value from the
> > first
> > request.
> >
> > But in the pjsip world, I am not easily finding this value, which is the
> > expires=x
> > value from the first REGISTER request. Then in the second request, I hope
> > to reject the errant registration based on the difference in contact
> > names
> > between
> > the two requests, and the fact the second request has expire=0, etc.
> >
> > Again, any help would be appreciated. Conversations like this could be
> > valuable
> > to developers needing to work on res_pjsip.
>
> The contact and expires is not stored on an endpoint. It's stored in a
> contact structure (which holds the details of the Contact header from
> the REGISTER) which is associated with the AOR. In fact I'd expect the
> code to work already with that Aastra specific usage. When
> res_pjsip_registrar got the unregister it would look for the associated
> contact to remove, but as there is none by the given Contact it
> shouldn't remove any.
>

​Many thanks, the above gives me a glimpse into the workings and
organsization in pjsip!​


​I have asked (again) the groups, and the folks that have reported problems
with pjsip,​

​are standing by their claims. The 53i and the 57i (iirc) are not able to
hold registration
on Asterisk 13.5, with either the as-is chan_sip driver, or the as-is pjsip
driver.

I am trying, without success so far, to get an old 53i going under pjsip in
my own
environment. It has been frustrating.

We have a patch for chan_sip dating back to the 1.6 days, that solves the
problem,
but only for chan_sip (even the one in 13.5). ​

If this is a bug in pjsip, and the framework of the existing driver is
truly already checking
the status of the "first" request vs the incoming request, then mayhaps we
can apply
the same sort of fixesin pjsip. Is this a bug, then? Should I file a bug
report?

murf


> --
> 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 --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 

Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉  murf at parsetree dot com
☎ 307-899-0510
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170417/3001aaa8/attachment.html>