[OpenSIPS-Users] How to modify the 100 Trying packet

Dave Singer dave.singer at wideideas.com
Tue Feb 8 08:17:22 CET 2011


I'm just trying to be helpful where I can, appreciative of the help
I've received and the great free software. My biggest worry is
misleading someone now or later in a list search. :-)

Just came across in another thread about the server header that you
can set it. Not sure of all the ramifications, I haven't tried it
myself.
Check out http://www.opensips.org/Resources/DocsCoreFcn16#toc66
You may want to try setting it to "" and see what happens. Though that
will affect any place it would use the Server header. Though I think
it is only a FYI header that is not required.

Seems like a very pick carrier. :-/  Oh the hoops they sometimes put
you through.

Dave

On Mon, Feb 7, 2011 at 8:14 PM, Tyler Merritt <tyler at fonality.com> wrote:
> Dave,
> Thanks for your reply.  I see you reply a lot and I appreciate you taking
> the time to help us.
> I read the page you linked - and I've stumbled across that before, but it's
> not what I want to do sadly :(
> The carrier basically wants me to strip the "Server" header from the 100
> message.  That's it - if this message went through the routing logic, I
> could just "remove_hf("Server");" but alas...
> I've told them this is a no-go for now.  Seems that we would have to modify
> the OpenSIPs core to make it happen.  Not worth the time or effort for this
> reason.
>
>
> On Tue, Feb 8, 2011 at 3:10 AM, Dave Singer <dave.singer at wideideas.com>
> wrote:
>>
>> The 100 Trying is sent out to the originating server/user
>> automatically when you send the invite off to the next destination
>> with t_relay and exit in the main routing script.
>> The 100 Trying you receive in the on_reply is just to let you know
>> that the next hop is not dead and it is working on it. Your server
>> only uses it for it's timeout for the call to that server.
>> See the optional flags in the t_relay docs:
>> http://www.opensips.org/html/docs/modules/1.4.x/tm.html#id271564
>> That should get you going.
>> FYI if (is_method("TRYING")) would always be false since the method is
>> INVITE and the status message would be Trying or "Giving a try" or
>> something else. Never count on the status message, just the code.
>> Different servers send back different messages. Unless you are
>> factoring that in.
>> I think you actually might be looking for fix_nated_contact. Check
>> that out. Depends on what you are trying to accomplish.
>>
>> Dave
>>
>> On Mon, Feb 7, 2011 at 3:48 AM, Tyler Merritt <tyler at fonality.com> wrote:
>> > This started working - but the problem is that it's matching both sides
>> > of
>> > the conversation.  I'm searching for a concrete method to say "only if
>> > you're going to send this packet to the upstream provider" but the
>> > closest I
>> > found was "is_destination" which has to be called from loose_route, and
>> > unfortunately it looks like we don't have any HF setup for this
>> > particular
>> > situation, so loose_route always returns 0 and exits (confirmed in the
>> > logs).
>> > The provider won't let me add stuff - maybe I can just add stuff one-way
>> > then rip it off on the return?
>> > if (is_method("INVITE") && status=="200" &&
>> > $(ct.fields(uri){s.substr,4,12})
>> > !~ '^8150*') {
>> >                                 xlog("L_INFO", "Modifying the outbound
>> > Contact header to Carrier...  $(ct.fields(uri){s.substr,5,12})");
>> >
>> >  subst('/^Contact:(.*)sip:[^@]*@[a-zA-Z0-9.]+(.*)$/Contact:
>> > <sip:$avp(oriUri)@192.168.0.2>/ig');
>> > }
>> > Any tips?
>> > On Mon, Feb 7, 2011 at 11:19 AM, Tyler Merritt <tyler at fonality.com>
>> > wrote:
>> >>
>> >> I have used "if (status=="100")" and "if (is_method("TRYING"))" and
>> >> placed
>> >> these in a variety of places, at the top of route[0], in route[1], in
>> >> onreply_route (where it actually works), but nowhere can I get the
>> >> OUTGOING
>> >> 100 TRYING packet to change...
>> >> I can't figure this out - there isn't very good documentation
>> >> surrounding
>> >> this particular packet, and if I were to guess, I would say that the
>> >> method
>> >> is hard-coded somewhere in the routing module.
>> >> Any pointers on where this packet might be modified before sending it
>> >> to
>> >> the upstream provider would be welcome.
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>> >
>
>



More information about the Users mailing list