SPA122: Diagnosing Dial in issue.

[wayne]

Hello All...

I have been asked to configure anSPA122 (and SPA112) to run on the Australian NBN. Particularly with the ISP Optus.

The ISP supplies a Sagem router/modem with VoIP capability. The customers network is such, that they must plug the WAN port of the supplied modem into their network. And the normal phone into the modem. In this configuration, people can dial in, and they can dial out.

In setting up the SPA122 or SPA112, we find that we can dial in, but can not dial out. 

As I have never run VoIP, I am hoping for an insight as to how to diagnose the issue.

Thanks for any ideas..!!!

:)

[Dan Lukes]

I assume the Sagem router is doing NAT and SPA112 is connected behind such NAT. Unfortunately, we know nothing about the flavor of the Sagem's NAT, especially how the NAT is doing with SIP packets passed thru.

So as a blind shot - try to disable all internal VoIP functions of Sagem. If SPA112 become working, then the issue is related to Sagem's internal interaction between external SIP traffic passed thru NAT and it's internal SIP client.

If you can capture packets on the outer interface of Sagem I can tell you more.

Although we may provide you an valuable advice even with Sagem configuration (if we will have data to analyze), you may consider to ask in an Sagem's support forum instead.

[wayne]

Hello Dan...

Thank you for your reply and interest in my question.

In this case, a different router is being used to connect to the Internet, an is it more functional and better than the ISP supplied Sagem.

The Sagem connects via its WAN port to a port on this current router. And as mentioned works fine.

The SPA112/122 also connects to this new router.

At no point are both solutions online at the same time. It's only "one at a time." 

I have WireShark logs for both solutions, but as they contain valid phone numbers, I prefer not to post them here. I am more than willing to supply them to you privately.

Again, thank you.

[Dan Lukes]

At no point are both solutions online at the same time. It's only "one at a time." 

I can't confirm. Even in this scenario, there are two devices behind the NAT (despite NAT is configured on different router, not the Sagem's one). SO we need to know how the NAT on other router is working with NAT. The only change is - the "blind shot advice" from my former comment can't be used ...

 I am more than willing to supply them to you privately.

My public email address of the day is <email address has expired>

Please disclose where the computer running wireshark has been connected in your current network topology (namely I need to know it has been connected on inner or outer side of the other router).

[wayne]

Dan...

Email sent.

Thank you. :)

[Dan Lukes]

OK, so i started reading the dump.

I will start with minor issue, unrelated to the case. You are trying to REGISTER with expires=120. Your service provider rejects it (423 Interval Too Brief) and claim Min-Expires = 1800. Fortunately, SPA112 will resend modified REGISTER automatically, so it ends in success. But every register needs to be repeated. You should tune your configuration accordingly to avoid it.

Also, your SPA112 is requesting G711u codec with RTP Packet Size of 0.03s. It's not only suboptimal (because Australian public phone network use 0.02s packet sice) but some switches are known to choke on it. I would like to recommend you to change  RTP Packet Size to 0.02. It may or may not cause the issue you are facing.

Now we can compare outgoing (successful)  Sagem's call with the failing SPA112's one. They are surprisingly dissimilar.

SAGEM session

Your INVITE with SDP (G711a with packet size 0.02)  is responded by 183 response with SDP created by 210.49.224.150 (G711a with packet size 0.02 and audio peer address 210.49.224.150) immediately followed by 180 response. I assume the Sagem is playing ring-back tone to you. Then you cancelled the call.

SPA112 session

Your INVITE with SDP (G711u with packet size 0.03)  is responded by 183 response with SDP created by 255.255.255.255 (G711a with packet size 0.02 and audio peer address 0.0.0.0). I assume you hear just silence. Then you cancelled the call.

I see no apparent reason for such difference in Nortel's response unless the Nortel soft-switch is the one failing on 30ms packet size requested.

My advice for SPA112 - change packed size to 0.02s, make G771a the most preferred codec (or better - the only codec supported).

Try again. Capture new SIP session if still failing.

Dan

[wayne]

Dan...

Thank you for your reply and time.

I have set the parameters as you mention, and the result is the same. I have a new log which holds results for both the SPA122 and Sagem. 

One difference I did notice, is that the "Status: 100 Trying" packet does not appear when dialing out on the SPA122. It does appear for the Sagem.

Please let me know what email to use to send the new log.

Again, thank you.

[Dan Lukes]

Yes, I noticed it as well. But 100 is the very preliminary optional response that depends on no INVITE content. It's up to your peer to decide send it or not to send it.

The 100 response is not the only suspicious difference, Even 183 is surprisingly different (see "Supported:" headers as well as "Sesson name" in SDP.

I will analyze your new dump (may be not this night), but you should be ready for final response like "only your provider can disclose the different behavior cause, here's no apparent reason for it from your side".

[Dan Lukes]

I analyzed new log you sent to me.

You solved the minor register issue and INVITE asks for G.711a codec with 20ms of packet time. It's the best we can do for Nortel softswitch on peer's side. Despite of it, Nortel is still sending very suspicious SDP content in 183 response:

---

---

With Connection information IP of 0.0.0.0 you will listen nothing, thus you have no call setup feedback (no progress tones like ring-back or busy tone).

Unfortunately, we have no chance to guess why Nortel softswitch is responding this to you. You should contact Optus's support for help.

Well, there's something you can try. The packets are captures on inner side of your border router. Such router is running NAT. We don't know the content of INVITE packet that passed thru NAT.

Imagine the NAT algorithm is buggy and can't take two independent inner SIP device correctly. Fortunately, it's easy to verify such hypothesis. Just turn off Sagem. Restart border router. Then try call from SPA122. If it will work, there's high chance your border router is responsible for the issue you are facing. If it will not work, only Optus may enlight us ...