[reSIProcate] Dum registration support for mulitple registrationsof different usernames

[Jason Fischl]

We don't really have GRUU support yet. It shouldn't be too much work
to finish it up although I'll point out that lots of proxies still
have serious issues with the +sip.instance parameter in the request
URI.

Jason


On 6/2/06, Scott Godin <slgodin at icescape.com> wrote:
> Sorry I didn't realize those functions were not even implemented.  You could
> just set the contact header yourself manually after you call makeRegsiter
> and before you call send.
>
> Scott
>
> -----Original Message-----
> From: Shaun Dawson [mailto:scdawson at gmail.com]
> Sent: Thursday, June 01, 2006 10:58 PM
> To: Scott Godin
> Cc: resiprocate-devel
> Subject: Re: [reSIProcate] Dum registration support for mulitple
> registrationsof different usernames
>
> In my version (revision 6264), addGruu is empty, and both hasGruu functions
> return false.  Am I missing something?
>
> --shaun
>
> On 6/1/06, Shaun Dawson <scdawson at gmail.com> wrote:
> > Scott,
> >
> > Thanks for all of this info.
> >
> > I'm using the resiprocate main trunk, which has the following code in
> > UserProfile.cxx:
> >
> > void
> > UserProfile::addGruu(const Data& aor, const NameAddr& contact) { }
> >
> > bool
> > UserProfile::hasGruu(const Data& aor) const {
> >    return false;
> > }
> >
> > bool
> > UserProfile::hasGruu(const Data& aor, const Data& instance) const {
> >    return false;
> > }
> >
> > Should I be using a different branch if I want to be able to use Gruus?
> >
> > Shaun
> >
> > On 5/29/06, Scott Godin <slgodin at icescape.com> wrote:
> > > Well the first two parameters on makeInitialRequest are used for
> > > Request-Uri and From field respectively.  For a registration request
> > > you would need to make these different only if you wanted to
> > > indicate that you are registering on someone else's behalf.  We
> > > should probably be allowing this in the API.
> > >
> > > The user used in the Contact header is taken from the 2nd argument
> > > to makeInitialRequest - the host and port are then populated by the
> > > stack, or taken from the profile setting OverrideHostAndPort.
> > >
> > > You can have an entirely different Contact by specifying a Gruu in
> > > the UserProfile.  Have a look at the code in
> > > BaseCreator::makeInitialRequest.
> > >
> > > Scott
> > >
> > > > -----Original Message-----
> > > > From: Shaun Dawson [mailto:scdawson at gmail.com]
> > > > Sent: Friday, May 26, 2006 5:25 PM
> > > > To: Scott Godin
> > > > Subject: Re: [reSIProcate] Dum registration support for mulitple
> > > > registrationsof different usernames
> > > >
> > > > I see.  But I can't register an AOR with a username that differs
> > > > from my own.  So, if I want to register sip:dawson at resiprocate.com
> > > > to the contact sip:scd111 at 10.10.10.10, I can't do that with the
> > > > Dum unless I fix that line, right?
> > > >
> > > > Shaun
> > > >
> > > > On 5/26/06, Scott Godin <slgodin at icescape.com> wrote:
> > > > > You can use multiple registration requests to register multiple
> > > users.
> > > > > You may need a separate UserProfile for each user - if
> > > authentication is
> > > > > required.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: resiprocate-devel-bounces at list.sipfoundry.org
> > > > > [mailto:resiprocate-
> > > > > > devel-bounces at list.sipfoundry.org] On Behalf Of Shaun Dawson
> > > > > > Sent: Friday, May 26, 2006 2:01 PM
> > > > > > To: resiprocate-devel at list.sipfoundry.org
> > > > > > Subject: [reSIProcate] Dum registration support for mulitple
> > > > > > registrationsof different usernames
> > > > > >
> > > > > > All,
> > > > > >
> > > > > > I believe that it is currently impossible to use DUM to
> > > > > > register
> > > more
> > > > > > than one username with a registrar.  This is because of line
> > > > > > 17 in RegistrationCreator.cxx, which uses the target for both
> > > > > > the aor
> > > and
> > > > > > contact usernames:
> > > > > >
> > > > > >    makeInitialRequest(target, target, REGISTER);
> > > > > >
> > > > > > I can correct this by changing this line to read:
> > > > > >
> > > > > >    makeInitialRequest(target, userProfile->getDefaultFrom(),
> > > > > REGISTER);
> > > > > >
> > > > > > which uses the DefaultFrom in the user profile instead of the
> > > target.
> > > > > >
> > > > > > Two questions:
> > > > > >
> > > > > > First, Is this the right way to do this?  It seems like it to
> > > > > > me,
> > > but
> > > > > > I can't believe that I'm the first person to have encountered
> > > > > > this issue in the Dum.
> > > > > >
> > > > > > Second, if this is the right way to do this, does anyone mind
> > > > > > if I
> > > go
> > > > > > ahead and make this change?  I believe that this will break
> > > > > > any existing implementations that do not properly set up a
> > > > > > user
> > > profile,
> > > > > > so I'm a little bit afraid of doing that.
> > > > > >
> > > > > > thanks,
> > > > > >   Shaun
> > > > > > _______________________________________________
> > > > > > resiprocate-devel mailing list
> > > > > > resiprocate-devel at list.sipfoundry.org
> > > > > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > > >
> > >
> >
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>