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

Re: [reSIProcate] outbound message decorators


Sorry for chiming in,

I just wanted to note that I always had the opinion that the decorator itself 
is responsible for 

- checking if a header exists, 
- then add or modify this header

so at least for me there is no problem with the current implementation...

Best regards,

Matthias


> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-devel-
> bounces@xxxxxxxxxxxxxxx] On Behalf Of Scott Godin
> Sent: Mittwoch, 12. März 2008 20:40
> To: 'Byron Campen'
> Cc: resiprocate-devel@xxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] outbound message decorators
> 
> Looking at the code I don't see where callOutboundDecorators is called for
> retransmissions.  SipMessage::callOutboundDecorators is called from
> TranportSelector::transmit.  Stack level re-transmissions are done via
> TransportSelector::retransmit.  I think the only problem is when dum is
> automatically responding to a digest challenge by issuing a new request.
> 
> Scott
> 
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: March 11, 2008 11:53 AM
> To: Scott Godin
> Cc: Neal Sidhwaney; resiprocate-devel; niklas.enbom@xxxxxxxxxxxx
> Subject: Re: [reSIProcate] outbound message decorators
> 
>       I think that the decorators _are_ being executed multiple times for
> 
> stack-level retransmissions here. This is a bug (after all, the point
> of the stack is to abstract away the SIP retransmission mechanism,
> and the decorator is application code). I'll look into fixing this.
> 
> Best regards,
> Byron Campen
> 
> 
> > I don't think this is necessarily a bug - outbound decorators are
> > triggered whenever a message is sent out on the wire (that is not a
> > stack level transmission).  401/407's are not exactly re-
> > transmissions,
> > they are new transactions that are generated at the UserAgent
> > layer.  I
> > do understand how it makes it difficult for the application to deal
> > with
> > this situation when it wants to manipulate a message only once.  Is
> > there something you can check to see if you've already decorated the
> > message before and if so avoid the subsequent decorations?
> >
> > Scott
> >
> >> -----Original Message-----
> >> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
> >> devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Neal Sidhwaney
> >> Sent: Friday, November 02, 2007 6:13 AM
> >> To: resiprocate-devel; niklas.enbom@xxxxxxxxxxxx
> >> Subject: [reSIProcate] outbound message decorators
> >>
> >> Hi
> >>
> >> I notice in DialogUsageManager line 796 the profile outbound message
> >> decorators are copied to the SipMessage outbound decorators. I am
> >> seeing that this causes the outbound message decorators to be
> >> executed
> >> more than once if the message is retransmitted, i.e. in the case of a
> >> 407 or 401 unauthorized returned from the server, thus my VIA headers
> >> are being added many times depending on how many times the message is
> >> resent.  Is this a bug?
> >>
> >> Thanks,
> >>
> >> Neal
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxx
> >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> 
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel