Yes Jeff, this is correct. Regards, Bogdan
Jeff Pyle wrote: > Hi Bogdan, > > I think I see what you're referring to. The domain of the From field at > INVITE time is not the same as the domain of the To field in the BYE from > the upstream proxy with the PSTN gateway behind it, correct? > > I verified it's the PSTN gateway changing the domain, not the upstream > proxy. > > > - Jeff > > > > On 7/28/09 8:44 AM, "Bogdan-Andrei Iancu" <bog...@voice-system.ro> wrote: > > >> Hi Jeff, >> >> I looked overt the trace you sent me and the problem is the not the RR >> param (as suspected), but the From URI which is changing across the >> dialog. If you look into the trace, you will noticed that the domain >> part (an IP actually) of the FROM header at INVITE time is different >> than the one from the TO header at BYE time. >> >> The param attached to the RR header is actually a diff between the old >> and new FROM URI so, you need to have the exact value for either old, >> either new URI - in your case, this is changes, the the diff results in >> a bogus value. >> >> Regards, >> Bogdan >> >> Jeff Pyle wrote: >> >>> Hi Bogdan, >>> >>> I'm into new territory here, so I'm not 100% sure what this is supposed to >>> look like. I can tell you that when I compare the Record-Route in the >>> INVITE I send to the PSTN gateway and the Route in the BYE I receive at >>> tear-down time, they are visually identical with all the same fields and all >>> the same values, including the vsf. >>> >>> You have the entire trace for your review if you like. >>> >>> >>> - Jeff >>> >>> >>> >>> On 7/23/09 3:27 AM, "Bogdan-Andrei Iancu" <bog...@voice-system.ro> wrote: >>> >>> >>> >>>> Hi Jeff, >>>> >>>> A common source of errors is the fact that the UAC / UAS do not properly >>>> mirror the RR parameters - if you could post the trace of the entire >>>> dialog, I will be able to say if it is the same or not in your case. >>>> >>>> Regards, >>>> Bogdan >>>> >>>> Jeff Pyle wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> In previous installations I've stayed away from uac_replace_from() because >>>>> in many cases I've seen it mangle the From field to the point where it's >>>>> out >>>>> of spec. This time I have to use it, and I'm not having much success. >>>>> >>>>> In addition to loading the appropriate modules, I have configured: >>>>> modparam("rr", "append_fromtag", 1) >>>>> modparam("uac","from_passwd","my_password") >>>>> modparam("uac","from_restore_mode","auto") >>>>> >>>>> I've read running it more than once on a transaction is bad news. I'm not >>>>> doing that. I'm running it once, something like this: >>>>> >>>>> $var(fromuri) = "sip:anonymous@" + $Ri; >>>>> uac_replace_from("anonymous", "$var(fromuri)"); >>>>> >>>>> I place an outbound call where this logic is hit, and all is well. It's >>>>> the >>>>> restore that happens on a loose-routed BYE from the network side when the >>>>> far end hangs up that seems to get things a bit out of whack. >>>>> >>>>> >>>>> The To field in this case, since it's backwards, is being restored as >>>>> follows, according to ngrep: >>>>> >>>>> To: "Voice Lab" >>>>> <sip:9998880...@11.22.33.44.:5060;transport=UDP>;tag=2378b50-0-13c4-6a31 >>>>> >>>>> What's interesting is the 11.22.33.44 address belongs to the upstream >>>>> proxy >>>>> that handed the call termination, not the originating one. My CPE >>>>> equipment >>>>> is complaining of an extra NULL character at the end of the address, which >>>>> ngrep shows above as a ".". >>>>> >>>>> I've tried it with variables, with static values >>>>> ("sip:anonym...@anonymous.invalid")... Something always gets mangled in a >>>>> most unfortunate way. >>>>> >>>>> This is on Opensips 1.5.1 on sparc. >>>>> >>>>> Any suggestions would be most appreciated. >>>>> >>>>> >>>>> Thanks, >>>>> Jeff >>>>> >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users@lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >>>>> >>>>> >>> >>> > > > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users