[asterisk-dev] Porting chan_sip patches res_pjsip

[Steve Murphy]

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.

Here is a copy of the debug trace from asterisk:



[Jun  5 09:52:47] VERBOSE[30653] chan_sip.c: [Jun  5 09:52:47]
<--- SIP read from UDP:10.254.129.246:5060 --->
REGISTER sip:10.254.131.239:5060 SIP/2.0^M
Via: SIP/2.0/UDP 10.254.129.246:5060;branch=z9hG4bK352d42fdf5650fdb0^M
Max-Forwards: 70^M
From: "Steve Murphy" <sip:zugzug49 at 10.254.131.239:5060>;tag=0e79afd6d8^M
To: "Steve Murphy" <sip:zugzug49 at 10.254.131.239:5060>^M
Call-ID: c1571fa76db23f00^M
CSeq: 15958 REGISTER^M
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK,
SUBSCRIBE, INFO^M
Allow-Events: talk, hold, conference, LocalModeStatus^M
Authorization: Digest username="zugzug49",realm="phonebooth.oneip.nl
",nonce="371cbeb9",uri="sip:10.254.131.239:5060
",response="073acacdc9b5d21a1ae7dd0237ee8db3",algorithm=MD5^M
Contact: "Steve Murphy" <sip:zugzug at 10.254.129.246:5060
;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1A1CBD>";expires=3600^M
Supported: path, gruu^M
User-Agent: Aastra 57i/3.3.1.2256^M
Content-Length: 0^M
^M

<------------->

...

[Jun  5 09:52:47] VERBOSE[30653] chan_sip.c: [Jun  5 09:52:47]
<--- SIP read from UDP:10.254.129.246:5060 --->
REGISTER sip:10.254.131.239:5060 SIP/2.0^M
Via: SIP/2.0/UDP 10.254.129.246:5060;branch=z9hG4bKe533d19f33262da61^M
Max-Forwards: 70^M
From: "Zimbabwe" <sip:oneip49 at 10.254.131.239:5060>;tag=d9305fc8ac^M
To: "Zimbabwe" <sip:oneip49 at 10.254.131.239:5060>^M
Call-ID: 78d50aec9c1f4d01^M
CSeq: 24058 REGISTER^M
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK,
SUBSCRIBE, INFO^M
Allow-Events: talk, hold, conference, LocalModeStatus^M
Authorization: Digest username="oneip49",realm="phonebooth.oneip.nl
",nonce="7319646a",uri="sip:10.254.131.239:5060
",response="1d350505fce24f726d609d037764959f",algorithm=MD5^M
Contact: "Zimbabwe" <sip:oneip49 at 10.254.129.246:5060
;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1A1CBD>";expires=0^M
Supported: path, gruu^M
User-Agent: Aastra 57i/3.3.1.2256^M
Content-Length: 0^M
^M

<------------->

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.

murf


-- 

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/20170412/8410ea6c/attachment.html>