< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Creating a DUM with automatic port?


        Yeah, my thoughts too.

Best regards,
Byron Campen

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




Attachment: smime.p7s
Description: S/MIME cryptographic signature