[Walford58]

Hi
I've just been putting a GSM gateway through its paces in conjunction with the SPA9000.
I've selected, for budget purposes, to use the Portech MV370, to use it as a link to a cell phone and port that cell to an extension to the PBX.
By following Humba3's sticky on the interop between SPA9000 and SPA3000, it worked OK.
The main problem is that the documentation from Portech is even worse than Linksys.
Has anyone else used this kit and got any pointers to make the interconnection more efficient?

Pete

[Walford58]

OK, I've got back to testing the MV370 further.

I just cannot get the thing to register with the SPA9000. Unfortunately the traces from the SPA don't include the messages from the MV370, so I can't read what is happening at that side.

However, by not registering, in the same way as using the SPA3102, outgoing calls are good and incoming calls also work.

I've come across a little problem, though - the SPA9k line 1 is registered on port 5060 - which is necessary for PlusNet and I have to use consistent NAT through the firewall.
I'm trying to get the MV370 to pass calls through to port 5063 (line 4), but it insists on sending them to line 1, so is routed through the wrong contact list. There seems to be no visible means of forcing the MV to send to another port. In fact port 5060 seems to be the only one it will use.

I've put a tech support request into Portech, but not sure I'll get much feedback from them.

Any suggestions?

Pete

[humba3]

You seem to be mixing things.. for once you say that the gateway cannot register with the SPA9k. Registering with the SPA9k means the gateway would act like an extension (and thus be prone to having the same registration issues so many devices have because the SPA9k contains at least 3 RFC violations in the REGISTER reply).

Then you mention line4.. that would mean the gateway would act like an IPTSP line.

Now, you can't have it both ways... it's either or (and that also determines where you should see trace messages... if the gateway is an extension, you need to activate traces on the sip proxy line, if it's an IPTSP line, you need traces on that line).

Also, unless the gateway acts as a proxy with registration, you wouldn't have the SPA9k register with the gateway (your first posts seems to suggest you have it set up as an IPTSP line but without registration).

debug level 3 will get you debug traces that show call routing.. so you can see why a call goes to the wrong line.

Then.. it turns out that the different port numbers aren't really necessary.. as long as you have different userids/proxies, messages will still go to the proper account. So you could set line4 to use port 5060.

[Walford58]

Thanks for your reply Humba3

Sorry, I don't think I was clear what I had been trying.

Originally Posted by humba3

You seem to be mixing things.. for once you say that the gateway cannot register with the SPA9k. Registering with the SPA9k means the gateway would act like an extension (and thus be prone to having the same registration issues so many devices have because the SPA9k contains at least 3 RFC violations in the REGISTER reply).

I tried registering with the SPA9k and it was successful as an extension. However that restricts what you can do with the gateway, so I only used that option as a check to see if the thing would register, which it does.

Originally Posted by humba3

Then you mention line4.. that would mean the gateway would act like an IPTSP line.

That's the approach I would prefer, but the two devices don't register with each other.

Originally Posted by humba3

if the gateway is an extension, you need to activate traces on the sip proxy line, if it's an IPTSP line, you need traces on that line).

I had traces on full on line 4 and it details the messages issued by the SPA9k, but doesn't record the ones from the gateway. As it seems to be using port 5060, perhaps I should temporarily log from line 1 as well to see if the messages are getting there.

Originally Posted by humba3

debug level 3 will get you debug traces that show call routing.. so you can see why a call goes to the wrong line.

I'll try again with the other line debug turned on.

Originally Posted by humba3

Then.. it turns out that the different port numbers aren't really necessary.. as long as you have different userids/proxies, messages will still go to the proper account. So you could set line4 to use port 5060.

I did try this one, and changed line 1 to be port 5063, but Line 1 failed to register with the ITSP until I returned it, and calls didn't get through to anywhere from the gateway. I will try this again, but this time with waiting for the line 1 registration to expire and to power cycle the SPA9k, in case a simple reboot doesn't do the trick.

It would be a great deal easier if Portech could allow me to select an alternative destination port, but at present they are mute on the subject.

Many thanks for your input.

Pete

****Update******
I changed the ports over again and rebooted. This time the gateway passes calls through the the correct line - still on port 5060, but now line 4.
Line 1 would not register whilst set to port 5063, but by forcing the external port to be 5060 to the ITSP, everything is fine.

So I'm a fairly happy bunny - got it working by adapting to the limitations of the equipment and advice from you.
Thanks.

Pete

[Walford58]

Further update:
Portech checked my settings and have put in a request for firmware update so that the port number is properly transmitted to the destination.