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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> > 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 >> > [email protected] >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> > > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
