[reSIProcate] Potential bug in TransportSelector

[Robert Sparks]

I don't think this will be baked enough for 1.1.

RjS

On Feb 9, 2007, at 8:20 PM, Byron Campen wrote:

> 	Of course. It'll require dumping a message on the TU's fifo, but  
> shouldn't require anything more complicated. (or, if we want to be  
> extra careful in case the TU might go away, we could do it through  
> the stack) Do we want to try to get this in 1.1, or do we want to  
> give it a release cycle to settle?
>
> Best regards,
> Byron Campen
>
>> This isn't straightforward since we have to potentially cross thread
>> boundaries.
>>
>> On 2/9/07, Byron Campen <bcampen at estacado.net> wrote:
>>>
>>>  Ok, so what we need to do here is have DUM (or any TU that acts  
>>> as an
>>> endpoint) register an outbound decorator that inspects the final,  
>>> filled-out
>>> Contact, and remember what it is, so it can keep track of its  
>>> dialog-state
>>> properly (and reuse the fully specified Contact for the rest of  
>>> the dialog).
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>
>>> (fixing the list address)
>>>
>>> If the TU explicitly specifies a transport, sure.
>>> But if the TU has asked the stack to deal with this for it, the  
>>> stack needs
>>> to populate the right things (think multiple interfaces with  
>>> different
>>> policies wrt transports).
>>>
>>> We may be running into a problem where we're saying the wrong  
>>> thing by
>>> telling the stack to do this by only leaving the hostname blank.
>>>
>>> RjS
>>>
>>>
>>>
>>>
>>> On Feb 9, 2007, at 2:22 PM, Byron Campen wrote:
>>>
>>>  I feel uneasy about touching the transport param at all; perhaps  
>>> the UAC
>>> put one into its Contact for a reason!  And if there wasn't one  
>>> there in the
>>> first place, I think it should be safe to assume the UAC doesn't  
>>> care what
>>> protocol stuff comes in on, so we shouldn't go adding one. I  
>>> assume that the
>>> UAC is at least aware of what kinds of transports (TCP,  
>>> UDP,TLS,...) it is
>>> listening on, and if its transport loadout is somehow incomplete,  
>>> it should
>>> be prepared to compensate for its lack of compliance by putting  
>>> explicit
>>> transport params into the Contact. My vote would be to remove the  
>>> code block
>>> altogether.
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>
>>> In TransportSelector::transmit we are seeing a bug in the  
>>> following case:
>>>
>>> UAC sends a SUBSCRIBE over transport at TCP:5060 and puts the  
>>> correct
>>> contact in the message
>>> UAC receives 200/SUBSCRIBE with a Record-Route of UDP:5061
>>>
>>> With the following code, we correctly send over UDP to target  
>>> 5061 but we
>>> leave transport=tcp in the Contact which causes a problem for the  
>>> UAS since
>>> it looks like a Contact refresh and subsequent requests from the  
>>> peer are
>>> sent to TCP:5061 where there is no listener.
>>>
>>>
>>>
>>>       if (target.transport)
>>>       {
>>>          // There is a contact header and it contains exactly one  
>>> entry
>>>          if (msg->exists(h_Contacts) &&
>>> msg->header(h_Contacts).size()==1)
>>>          {
>>>             for (NameAddrs::iterator
>>> i=msg->header(h_Contacts).begin(); i !=
>>> msg->header(h_Contacts).end(); i++)
>>>             {
>>>                NameAddr& contact = *i;
>>>                // No host specified, so use the ip address and  
>>> port of the
>>>                // transport used. Otherwise, leave it as is.
>>>                if (contact.uri().host().empty())
>>>                {
>>>                   contact.uri().host() =
>>> (target.transport->hasSpecificContact() ?
>>>
>>> target.transport->interfaceName() :
>>>
>>> Tuple::inet_ntop(source) );
>>>                   contact.uri().port() = target.transport->port();
>>>
>>>                   if (target.transport->transport() != UDP)
>>>                    {
>>>                       contact.uri().param(p_transport) =
>>> Tuple::toData(target.transport->transport());
>>>                    }
>>>
>>>
>>> My proposal is to remove the if (target.transport->transport() !=  
>>> UDP). Does
>>> anybody remember why this is here?
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at list.resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at list.resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>>
>>>
>