Re: [reSIProcate] Creating a DUM with automatic port?
It appears you would need to refresh the Tuple after binding (in
InternalTransport::bind()) using getsockname().
Brad
Byron Campen <bcampen@xxxxxxxxxxxx> wrote on 31/01/2007 03:40:06 AM:
> Hrm. I guess this could be useful for clients. It looks like we
> would have to make the changes necessary to allow the caller to
> determine which port the transport was ultimately created on. Is this
> a high priority?
>
> Best regards,
> Byron Campen
>
> > I don't think that is what most people would expect. Passing a
> > port of
> > 0, I would expect that the operating system would choose an
> > appropriate
> > free port for me. However I'm not sure if this capability is
> > portable.
> > Does anyone know?
> >
> > Scott
> >
> >> -----Original Message-----
> >> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> >> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of
> >> Byron Campen
> >> Sent: Tuesday, January 30, 2007 11:09 AM
> >> To: Bradley Gorman
> >> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [reSIProcate] Creating a DUM with automatic port?
> >>
> >> Yeah, this looks broken. I think it would be reasonable to
> > expect
> >> the stack to select the default SIP port for the transport you are
> >> adding if no port is specified. Does anyone disagree?
> >>
> >> Best regards,
> >> Byron Campen
> >>
> >>> Hi All
> >>>
> >>> I've found something in reSIP that confuses me.
> >>>
> >>> I have a SIP client using the DialogUsageManager. I am trying to use
> >>> addTransport() to specify that it should connect via UDP and/or TCP
> >>> and I don't particularly care what port it should connect from (of
> >>> course, I would prefer an ephemeral port). The prototype for
> >>> SipStack::addTransport() implies I should be able to omit the port
> >> and
> >>> use a default of 0, however the implementation of this function
> >>> immediately asserts that the port should be greater than 0. From
> > what
> >>> I have seen, reSIP just calls bind() with a normal sockaddr
> >> structure.
> >>>
> >>>> From this I would assume I can allow it to select a port for me,
> >>>> using a
> >>> port of 0, although the assertion implies I should not. I would
> >> prefer
> >>> not to select my own ephemeral port so I do not have to handle any
> >>> collisions with in-use ports.
> >>>
> >>> Am I using the DUM correctly by trying to add the desired transport
> >>> with a default port of 0?
> >>> Is there any reason I should NOT specify port 0?
> >>>
> >>> The relevant code snippets are below
> >>>
> >>> Thanks
> >>>
> >>> Brad
> >>>
> >>>
> >>> My client:
> >>>
> >>> dum.addTransport(resip::UDP, 12345, resip::V4);
> >>> // always uses local/client port of 12345 (BAD!)
> >>>
> >>> dum.addTransport(resip::UDP, 0, resip::V4);
> >>> // assertion failure (port > 0)
> >>>
> >>> dum.addTransport(resip::UDP);
> >>> // assertion failure (port > 0)
> >>>
> >>>
> >>> resip/stack/SipStack.hxx:
> >>>
> >>> Transport* addTransport( TransportType protocol,
> >>> int port=0,.
> >>> IpVersion version=V4,
> >>> StunSetting stun=StunDisabled,
> >>> const Data& ipInterface = Data::Empty,.
> >>> const Data& sipDomainname = Data::Empty, //
> >>> only used
> >>> //
> >> f
> >>> or TLS
> >>> //
> >> b
> >>> ased stuff.
> >>> const Data& privateKeyPassPhrase =
> >>> Data::Empty,
> >>> SecurityTypes::SSLType sslType =
> >>> SecurityTypes::TLSv1);
> >>>
> >>>
> >>> resip/stackSipStack.cxx:
> >>>
> >>> SipStack::addTransport( TransportType protocol,
> >>> int port,.
> >>> IpVersion version,
> >>> StunSetting stun,
> >>> const Data& ipInterface,.
> >>> const Data& sipDomainname,
> >>> const Data& privateKeyPassPhrase,
> >>> SecurityTypes::SSLType sslType) {
> >>> assert(!mShuttingDown);
> >>> assert( port > 0 );
> >>> ...
> >>> }
> >>> _______________________________________________
> >>> resiprocate-devel mailing list
> >>> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> >>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
>