Summary:	ASTERISK-23173: PJSip missing feature: SIPPEER
Reporter:	xrobau (xrobau)	Labels:
Date Opened:	2014-01-21 16:00:02.000-0600	Date Closed:	2016-02-08 14:06:49.000-0600
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	12.0.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	There is no equivalent feature of 'SIPPEER' for PJSip endpoints.
Comments:	By: Matt Jordan (mjordan) 2014-01-21 16:42:27.756-0600 This one I think we got - [PJSIP_ENDPOINT|https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Function_PJSIP_ENDPOINT] function. By: xrobau (xrobau) 2014-01-21 18:26:29.963-0600 That's what I thought, but that just DESCRIBES the endpoint, and doesn't let your query anything about it - eg, the User Agent of the device (which SIPPEER can do) (Or am I blind?) By: Matt Jordan (mjordan) 2014-01-21 19:01:49.254-0600 No, you're right about useragent. PJSIP_ENDPOINT does get *most* of what is in SIPPEER, but there's a number of things that I wouldn't think are SIP endpoint related items in SIPPEER as well. Going down the list: | ip - (default) The IP address. | Yes, through the CHANNEL function (pjsip,local_addr/remote_addr) | | port - The port number. | Yes, through the CHANNEL function (same) | | mailbox - The configured mailbox. | Yes, PJSIP_ENDPOINT function | | context - The configured context. | Yes, PJSIP_ENDPOINT | | expire - The epoch time of the next expire. | I'm not sure how this is useful, so no. | | dynamic - Is it dynamic? (yes/no). | No, but again, I'm not sure how this is useful. | | callerid_name - The configured Caller ID name. | No, but we shouldn't either. CALLERID function does this. | | callerid_num - The configured Caller ID number. | No, but again, we shouldn't do this. | | callgroup - The configured Callgroup. | Yes, PJSIP_ENDPOINT | | pickupgroup - The configured Pickupgroup. | Yes, PJSIP_ENDPOINT | | namedcallgroup - The configured Named Callgroup. | Yes, PJSIP_ENDPOINT | | namedpickupgroup - The configured Named Pickupgroup. | Yes, PJSIP_ENDPOINT | | codecs - The configured codecs. | Yes, PJSIP_ENDPOINT (allow) | | status - Status (if qualify=yes). | No. This might be useful. | | regexten - Extension activated at registration. | No. This may or may not be useful; I'm not sure how it would be used right now. | | limit - Call limit (call-limit). | No, and call-limits have been obsoleted for some time. | busylevel - Configured call level for signalling busy. | No, and PJSIP doesn't really work that way. | | curcalls - Current amount of calls. Only available if call-limit is set. | No. It might be useful to have some way to determine how many channels are associated with that - but that would be drilled through the AOR | | language - Default language for peer. | Yes, PJSIP_ENDPOINT | | accountcode - Account code for this peer. | No, which means we probably need it as a feature on an endpoint (whoops). It would be accessible through PJSIP_ENDPOINT. Granted, you can set this using CHANNEL still, but having it as a convenience (all channels created through this endpoint get this accountcode) is nice and relatively common. | | useragent - Current user agent header used by peer. | Nope. This feels like a CHANNEL thing (useragent of the active dialog). | | maxforwards - The value used for SIP loop prevention in outbound requests | No, not sure this is needed. | | chanvarname - A channel variable configured with setvar for this peer. | Kind of. You could drill through PJSIP_ENDPOINT to get this, but multiple values would be interesting to extract. Again, not sure how this is very useful - why not just get the channel variable? | | codecx - Preferred codec index number x (beginning with zero). | No, but this might be useful. I'd prefer to do it through a different mechanism however. | So it's a mixed bag. Looking at what we don't have, I'd group it into one of the following categories: * Information about the current registration. I'd rather have a function that provides that run-time information, rather than crowding the CHANNEL or PJSIP_ENDPOINT. PJSIP_REGISTRATION maybe? * Run-time PJSIP information about the channel. In general, these should probably be added to CHANNEL where appropriate. Media information is a bit tricky; it may end up running into/combined with PJSIP_MEDIA_OFFER. By: xrobau (xrobau) 2014-01-22 12:56:38.592-0600 With 'useragent' we currently use that to query devices so we know what headers to send them to auto answer.  I believe we also use curcalls for in-use detection, too. By: Joshua C. Colp (jcolp) 2014-01-22 12:59:15.619-0600 The wrinkle with useragent is that you want the useragent of any contacts associated with the endpoint, of which there may be multiple. It complicates things a bit. One option is to allow contacts to be queried from the dialplan and then use a pre-dial handler. By: xrobau (xrobau) 2016-02-08 13:59:36.321-0600 Looks like this was implemented in Asterisk 13? https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_PJSIP_CONTACT By: Joshua C. Colp (jcolp) 2016-02-08 14:06:49.308-0600 You appear to be correct.