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

RE: [reSIProcate] How to modify the Contact field of SIP message ?


OK, I finally implemented this and it works fine.

Profile now has three new member functions:

          virtual void setOutboundDecorator(SharedPtr<MessageDecorator> 
outboundDecorator);
          virtual SharedPtr<MessageDecorator> getOutboundDecorator();
          virtual void unsetOutboundDecorator();

In DialogUsageManager I added the following to the send function:


[   if (msg->isRequest()) ......]

           // Add outbound decorator from userprofile
           SharedPtr<MessageDecorator> outboundDecorator = 
userProfile->getOutboundDecorator();
           if (outboundDecorator.get())
                   msg->addOutboundDecorator(outboundDecorator.get());

The decorator will automatically called by the stack
after transport selection. Unfortunately that duplicates
the outgoingMessageInterceptor feature a bit, but 
the MesssageDecorator interface has existed anyway - it just
wasn't usable in combination with dum before. Apart from that 
it's more powerful because:

- the decorator can depend on the profile
- the decorator is called right before the message is sent

Due to these issues this seems to me the best solution that 
allows you to set the via headers correctly for STUN 
situations, so I don't think anyone would mind me checking
this in?


Best regards,

Matthias Moetje


> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Matthias Moetje - TERASENS GmbH
> Sent: Monday, April 17, 2006 10:57 PM
> To: Scott Godin; Dmitry Semyonov
> Cc: resiprocate-devel
> Subject: RE: [reSIProcate] How to modify the Contact field of 
> SIP message ?
> 
> 
> > What about adding the sip message decorator for all dum 
> messages in an 
> > outgoingMessageInterceptor?
> 
> The bigger problem with this is that I don't want to change 
> via for all outgoing messages but only for those which are 
> sent to the public internet (with STUN). This depends on the 
> profile (I have profiles for local and public endpoints). 
> Seems I need to stick with my current proposed solution..?
> 
> 
>  
> > > -----Original Message-----
> > > From: Matthias Moetje - TERASENS GmbH [mailto:moetje@xxxxxxxxxxxx]
> > > Sent: Monday, April 17, 2006 2:40 PM
> > > To: Scott Godin; Dmitry Semyonov
> > > Cc: resiprocate-devel
> > > Subject: RE: [reSIProcate] How to modify the Contact field of SIP 
> > > message ?
> > > 
> > > Hi Scott,
> > > 
> > > I agree that setOverrideHostAndPort should also set the 
> contact for 
> > > responses.
> > > You could also remove the comment for this function 
> > regarding setting 
> > > the via because this doesn't work.
> > > (because via is used for transport selection)
> > > 
> > > I am currently looking at the best way to modify the via. The 
> > > outgoingMessageInterceptor is nice but it doesn't really 
> help here 
> > > because it is executed before transport selection.
> > > 
> > > Fortunately there already exists a different feature in the 
> > stack: The 
> > > OutboundDecorator. You can add an arbitrary number of outbound 
> > > decorators to a SIP message which are executed _after_ transport 
> > > selection.
> > > I already implemented this but this works only for 
> messages I have 
> > > access to like INVITE or REGISTER but not for messages which are 
> > > created by DUM (like ACK or BYE).
> > > 
> > > My idea is now to add a "setOutboundDecorator" to the 
> > userprofile and 
> > > modify DUM's makeRequest and makeResponse functions to 
> > automatically 
> > > add the outbound decorator from the profile if present.
> > > 
> > > (First I thought about always copying the outbound 
> > decorators from the 
> > > original message when creating messages, but I think the 
> > userprofile 
> > > approach is much better)
> > > 
> > > Would you have any concerns about this new feature?
> > > (I could not think of any other method for modifying the 
> > via without 
> > > making intrusive changes to the transport selection itself)
> > > 
> > > 
> > > Best regards,
> > > 
> > > Matthias Moetje
> > > ______________________________________________
> > > 
> > > TERASENS GmbH       Phone:  +49.89.143370-0
> > > Augustenstraße 24   Fax:    +49.89.143370-22
> > > 80333 Munich        e-mail: info@xxxxxxxxxxxx
> > > GERMANY             Web:    www.terasens.com
> > > ______________________________________________
> > > 
> > > > -----Original Message-----
> > > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On 
> > Behalf Of 
> > > > Scott Godin
> > > > Sent: Monday, April 17, 2006 3:31 PM
> > > > To: Dmitry Semyonov
> > > > Cc: resiprocate-devel
> > > > Subject: RE: [reSIProcate] How to modify the Contact 
> field of SIP 
> > > > message ?
> > > >
> > > > Actually I have been thinking about this lately.  Is there any 
> > > > reason that we wouldn't want setOverrideHostAndPort to 
> > also set the 
> > > > contact on dialog responses as well?  This way it will always 
> > > > override the contact
> > > > - ie. both of newly created requests and for responses.
> > > >
> > > > Note:  DUM now has an outgoingMessageInterceptor that may 
> > serve the 
> > > > purpose of decorating responses.
> > > >
> > > > Scott
> > > >
> > > > > -----Original Message-----
> > > > > From: Dmitry Semyonov [mailto:dsemyonov@xxxxxxx]
> > > > > Sent: Friday, April 14, 2006 12:54 PM
> > > > > To: Scott Godin
> > > > > Cc: Asheesh Joshi; resiprocate-devel
> > > > > Subject: RE: [reSIProcate] How to modify the Contact 
> > field of SIP
> > > > message
> > > > > ?
> > > > >
> > > > > Hello Scott, et al,
> > > > >
> > > > > On Mon, 17 Oct 2005, Scott Godin wrote:
> > > > >
> > > > > > You should be able to use the new onReadyToSend callback
> > > > and modify
> > > > > > the Contact header of 200/Invites.
> > > > >
> > > > > Recently I expected setOverrideHostAndPort() to do the 
> > trick for 
> > > > > provisional responses, but it does not work. 
> onReadyToSend() is 
> > > > > not going to work either as it is called only for requests.
> > > > >
> > > > > (I tested with outdated reSIProcate, but looking through
> > > > the code the
> > > > > functionality is same in up-to-date version.)
> > > > >
> > > > > Am I missing something? Are there any way to set 
> custom Contact 
> > > > > for responses? TIA
> > > > >
> > > > > BTW, I don't agree that modifying Contact to the value of
> > > > Request-URI
> > > > > is mandated by the RFC.
> > > > >
> > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
> > > > Behalf Of
> > > > > > Asheesh Joshi
> > > > > > Sent: Monday, October 17, 2005 9:00 AM
> > > > > >
> > > > > >             As per RFC 3261, reciprocate rightly 
> modifies the 
> > > > > > contact field for a Request to the Request-URI of the 
> > incoming 
> > > > > > packet.
> > > > > >
> > > > > >             I am using DUM and I want to set the Contact
> > > > header to
> > > > > > my IP in the 200 OK for INVITE. Is there a Interface 
> > to achieve 
> > > > > > this?
> > > > >
> > > > > --
> > > > > ...Bye..Dmitry.
> > > > _______________________________________________
> > > > resiprocate-devel mailing list
> > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> > > >
> > 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>