Hi Jeff, >> >> How do you jump from the failure route back to the request route? route(X) >> or are you t_relay-ing to yourself? I don't remember right now exactly to >> which message changes would be applied if you do stuff on the failure route. > > With a route[x] statement. I had some of these functions occurring at the > failure route, but I had the same issues. I tried to simply things by having > everything happen at the same place, in this case, in the request_route just > prior to the t_relay out to the carrier. > >>> Everything above works okay in testing. It's only in production do I start >>> to see a small percentage of 400s and 488s coming back from the term >>> carriers because of the mangled SDP lines. I can take the call flow of one >>> of the failed calls, duplicate it, and it will work fine. That leads me to >>> believe there's some sort of timing issue at work here causing the >>> unintended SDP manglage even though I'm running only one of these functions >>> at a time. >>> >>> Does anything jump out at you? >>> >> >> Since the routing script will be executed top to bottom, I don't see how >> timing could be an issue here :-S Sorry I can't be of much help here, if >> something comes to ming I'll come back to you. > > My thought on timing was items not being updated between Opensips processes, > or perhaps within the dispatcher itself. I have a fresh 400 example in front > of me where the first carrier attempt required media relay, returned a 503, > so we looped around to the second carrier attempt, also requiring a media > relay. If that execution of use_media_relay caused another session to be > generated somewhere, instead of updating the original one from the previous > carrier attempt, I can see where it might cause this symptom where it appears > the function was called twice. Or am I barking up the wrong tree? >
Calling route(x) from the failure route is not the same as getting a new message into the proxy. When you add headers to the message in the main route you can't remove them in the failure route, you need to use a branch route. Same case applies here. In the case you described above you would call use_media_proxy twice for the same message. I think this would solve your problem: call use_media_proxy on a branch route and end_media_session on the failure route in case the gateway returns 503. Regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
