[Home]

Summary:ASTERISK-01816: [patch] Added support for Remote-Party-ID
Reporter:nogren (nogren)Labels:
Date Opened:2004-06-14 04:29:47Date Closed:2008-01-15 14:58:49.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) rpid-01.diff
( 1) rpid-new.patch.gz
( 2) rpid-new.txt
( 3) rpid-trust.diff
Description:Read in the Remote-Party-ID header to the sip_pvt structure, and if privacy not set, use that number as A number instead of the number found in "from". Can be used in chan_modem_i4l to set correct A number. Patch for that is included as well.

****** ADDITIONAL INFORMATION ******

The patch made may need this patch first, to be applied correctly:
http://bugs.digium.com/file_download.php?file_id=2063&type=bug

Comments:By: nogren (nogren) 2004-06-14 07:13:00

Forgot to check for non existing remote-party-id header.. new patch uploaded.
By: Olle Johansson (oej) 2004-06-14 07:23:50

Please don't upload .gz when the file size is so small, a .txt makes it easier to read your patch in a browser. Uploaded same file, with .txt extension.
By: Olle Johansson (oej) 2004-06-14 07:26:59

I do not think we should accept remote-party-id: from every SIP device, it should be configurable by [user].

Trust-rpid=yes|no

What do you think?
By: nogren (nogren) 2004-06-14 07:35:03

Well, as I wrote in the corresponding e-mail on asterisk-dev mailinglist, I solve that problem somewhere else (SER). i don't have any [user] record for my SER, so then I would like a overall config that will be enable|user|disable. What do you think about that?
By: Olle Johansson (oej) 2004-06-14 07:41:07

You can both have a global setting and a per-user, but the per-user is really important. If you follow the rest of the SIP settings,
it should be the same setting syntax for both users, peers and for the general setting. Yes | no is the syntax used today so enable|disable is not a good syntax.
By: Mark Spencer (markster) 2004-06-14 09:14:00

OEJ: can you think of any situation where "Remote-Party-ID" could be forged and "From" could not?

If "privacy=full" is selected, we should still populate the ANI field and but not the Caller*ID field.  If "sendani" is enabled on a peer, then we can send using Remote-Party-ID as well.
By: Mark Spencer (markster) 2004-06-14 09:14:24

Also, do you have a disclaimer on file?
By: Olle Johansson (oej) 2004-06-14 09:32:02

markster: Well, I don't send the From: header to the PSTN, but may send RPID, so I want to be able to choose who I trust or not in this case.
By: nogren (nogren) 2004-06-14 10:16:16

My primary target is to send number as A number on PSTN, so I need to validate and trust what I do. The Caller*ID field should not be used, but I don't know  a better mechanism for the moment. Perhaps someone else can create a global "sendani" variable, and one ani variable populated with the number if trusted. I have soon another patch for chan_sip ready where I consider all the trust from sip.conf.
By: nogren (nogren) 2004-06-14 10:33:59

Some more patch for chan_sip, to check if peer/user is trusted, or global switch for trusted, before using rpid instead of from. As said before, is there a use:able global (channel) variabel for A number storage, and if it is useable (privacy!=full)?
By: nogren (nogren) 2004-06-15 09:15:26

Well, new complete diff-file with functions for taking the Remote-Party-ID header into sip_pvt, setting restrictedcid if privacy according to the header, and if trustrpid also set Caller*ID to this number. In chan_modem_i4l : i4l_dial the number is used if not restrictedcid, and if allowed according to config.
By: nogren (nogren) 2004-06-18 08:02:14

Disclaimer faxed to Digium.
By: Mark Spencer (markster) 2004-06-18 09:14:07

Okay, getting closer now, still some issues I'd like to get cleared up:

1) If the outgoing MSN is 1234,5678 then "234" will be considered a valid number.  is that your desired behavior?  You could put "," at the beginning and end of the outgoingmsn field when you fill it in, so that you could strstr on ",msn," as an easy, quick and dirty grab to keep this code simple.

2) Please use tabs instead of spaces to match existing formatting.

3) get_rpid_num needs a little work for security:

3a) When you "strncpy" the number you need to strncpy with is the size of the buffer you are copying into, minus one.  That size needs to be passed to get_rpid_number from the caller.

3b) Also remember that setting "output=NULL" before returning accomplishes nothing since output is a pointer on the stack and its value is not returned to the calling program.  Instead you can do output[0] = '\0'; or simply strcpy(output,""); to indicate nothing useful is there.  

3c) The variable "start" and "end" are incremented and decremented before they are checked for NULL-ness.  Even if they're not there, that test would always pass, and would obviously cause a seg fault.

3d) Why is remote_party_id stored in the sip_pvt structure?  It would appear it's only used locally within that one function.

Other than that, looks pretty good.  I look forward to a revised patch, and thanks again for your contribution!
By: Mark Spencer (markster) 2004-06-21 00:43:49

I went ahead and added it with the changes I had recommended.
By: Digium Subversion (svnbot) 2008-01-15 14:58:49.000-0600

Repository: asterisk
Revision: 3253

U   trunk/channels/chan_modem.c
U   trunk/channels/chan_modem_i4l.c
U   trunk/channels/chan_sip.c
U   trunk/configs/modem.conf.sample
U   trunk/configs/sip.conf.sample
U   trunk/include/asterisk/vmodem.h

------------------------------------------------------------------------
r3253 | markster | 2008-01-15 14:58:48 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge outgoing MSN support + Remote Party ID for SIP (bug ASTERISK-1816) with cleanups

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=3253