Red5 & SIP Phone Plugins - Spark vs. SparkWeb Behavior

Dear All,

I have been experimenting with the whole setup, Red5, SIP Phone Plugins integrated in OpenFire and its Spark and SparkWeb clients and I am impressed more and more every day. However, I still struggle with the connectivity to external SIP account.

For instance, when I trace via Wireshark I can see that the SIP Phone Plugin within OpenFire will treat the SIP account information different than the Red5 plugin in SparkWeb. This is confusing me a lot. Below are examples of configurations that provide at least partial results. The first is the SIP Phone plugin configuration with which I pass the REGISTER Test successfully.

SIP username : +421477000615@siplink.com

Authorization Username : 421477000615@one.mnc003.mcc230.3gppnetwork.org

Display Phone Number : +421477000615

Password : **********

Server : siplink.com

Outbound Proxy : siplink.com

Voice Mail Number : 123

But then in Red5, the same config will cause of “Bad To” Error, because it takes the Server@Server as a to argument and I don’t know why. Then I used the Red5 test page and tried to alter the configuration there and had to use the following in order to pass to at least another round in the REGISTER handshake, but finally end up with Error code 503 anyways. I don’t know why OpenFire with Spark behave different than SparkWeb with respect to the SIP account configuration.

Phone#: +421477000615

Username: +421477000615

Password: **********

MailBox: 123

SIP Realm: one.mnc003.mcc230.3gppnetwork.org

SIP Server: siplink.com

Red5 URL: rtmp:/sip

Req. Failure = 503 CX Unable To Comply

Dele, or someone else, can you please clarify and perhaps lead me to a configuration that would be successful. I have used an alternative SIP operator with whom I have been able to Test REGISTER and I could also get a dial pad in the Spark client, but never got a dial pad in SparkWeb - I think this is because the configuration that I have used is interpreted differently by Red5 / SparkWeb.

Thank you for any suggestions that you might have!

Regards,

Petr