[reSIProcate] Creating a DUM with automatic port?

Byron Campen bcampen at estacado.net
Tue Jan 30 12:40:06 CST 2007


	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 at list.resiprocate.org
>> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
>> Byron Campen
>> Sent: Tuesday, January 30, 2007 11:09 AM
>> To: Bradley Gorman
>> Cc: resiprocate-devel at list.resiprocate.org
>> 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 at list.resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070130/6b3e3630/attachment.bin>


More information about the resiprocate-devel mailing list