On Sat, Dec 27, 2008 at 11:51 AM, Melcon Moraes <[email protected]> wrote: > On Sat, Dec 27, 2008 at 2:41 AM, M. Ranganathan <[email protected]> wrote: >> On Fri, Dec 26, 2008 at 11:06 PM, M. Ranganathan <[email protected]> wrote: >>> On Fri, Dec 26, 2008 at 10:09 PM, M. Ranganathan <[email protected]> wrote: >>>> On Fri, Dec 26, 2008 at 6:48 PM, Arnaldo de Moraes Pereira >>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On Wed, Dec 24, 2008 at 5:56 PM, Melcon Moraes <[email protected]> wrote: >>>>>> >>>>>> On Wed, Dec 24, 2008 at 1:13 AM, M. Ranganathan <[email protected]> wrote: >>>>>> > On Tue, Dec 23, 2008 at 7:59 PM, M. Ranganathan <[email protected]> >>>>>> > wrote: >>>>>> >> On Tue, Dec 23, 2008 at 4:57 PM, Melcon Moraes <[email protected]> >>>>>> >> wrote: >> >>> Arnaldo, you have correctly identified the problem. What I was >>> describing above is what happens for INVITEs that originate from >>> within sipx. However, in this case you have the INVITE coming into >>> sipxbridge from the ITSP side. >>> >>> Looking through your trace file, sipxbridge sees of an inbound request >>> from the "ITSP" (in your case you do not really have an ITSP). >>> Unfortunately, here I cannot ITSP account for this request. I have no >>> a-priori idea of where the request originated from and hence I have to >>> default to to using a global address. This is the mode of behavior >>> that ITSPs generally expect. Those that support REGISTER use private >>> addressing to identify that a request originated from behind a NAT. In >>> this case, I have the address of the ITSP and can hence match it to >>> subsequent inbound requests. In your case, you do not requre a >>> REGISTER. Then out of the blue I see a request from you and have no >>> idea what "ITSP" that came from so I default to the global addressing >>> scheme. >>> >>> If you want to use private addressing I suggest you add a dummy >>> Registrar to your "ITSP". This will enable me to identify subsequent >>> requests as belonging to that ITSP. Off hand that would be the >>> simplest thing to do. >>> >>> >>> Ranga >>> >>> >>> >>> -- >>> M. Ranganathan >>> >> >> >> Actually this analysis of mine is not quite right in this case. >> Looking at your sipxbridge.xml file and your signaling, you have set >> it up using all direct addresses so that it can indeed be identified. >> I simply had not considered the case where you have no registration >> but still want private signaling. I will admit I have never seen an >> ITSP need such signaling but in theory it is possible. >> >> I made a fix in the code to accommodate this case and committed >> something. Please try r14373 >> >> Ranga >> >> >> >> -- >> M. Ranganathan >> > > Very nice, Ranga. > > Regarding the REGISTER, I think I tried before with it and got the > same results. Let me check that and post it back in here. > > After that, I'll try your last changes and see how it goes. > > Thanks > > -MM >
False alarm Ranga. I did the tests again with r14285 and r14372 registering with my "ITSP" and both worked as you described regarding Account identification. Now it is time to go for r14373, which I'm pretty sure will work both ways. Thanks again. -MM _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
