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@10.254.131.239:5060>;tag=0e79afd6d8^M To: "Steve Murphy" <sip:zugzug49@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@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@10.254.131.239:5060>;tag=d9305fc8ac^M To: "Zimbabwe" <sip:oneip49@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@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
-- _____________________________________________________________________ -- 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