Re: [reSIProcate] Potential bug in TransportSelector

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

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