[sip-comm-dev] Problem: can't establish outgoing calls with SIP Communicator


#1

Dear SIP Communicator developers,

I have had a chat with Lubomir Marinov this afternoon (he asked me to post on this list as well) regarding a problem I encounter when using SIP Communicator:
I am unable to establish any outgoing calls. Whenever I try to call a contact/number, the "call window" opens, displays "connecting" for a short period of time, but always changes to "failed". I am on Windows Vista, the SIP provider in question is Vodafone Germany, formerly Arcor. Interestingly, I am able to call my other accounts/numbers registered with Vodafone (as my "landline" provider) but no "external" providers/numbers. Receiving incoming calls works like a charm, no matter where they originate from.
I have tried several other softphones (e. g. PhonerLite, Qutecom, ...) with Vodafone as provider and they all worked well without any troubles.
Please find attached a logfile, which I retrieved from a "clean", i. e. new installation of SIP Communicator after starting up the software, entering my SIP account details and trying to call my cellphone unsuccessfully. I hope this helps to shed some light on my problem, I'm happy to provide any additional information if needed. (Lubomir has pointed out the helpfulness of Wireshark dumps, but as I haven't used this software before, I would need some more time to have a look at it...)

I appreciate your help, as I would love to use SIP Communicator as multimessenger/voip-application in the future!
Thank you very much in advance,

Johannes Albert

sip-communicator0.log.0 (351 KB)


#2

Hi Johannes,

looking at the SIP protocol of your call I see the following data (starting
at line 2545 in your log file):

SIP/2.0 503 Service Unavailable
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 2 INVITE

From: <sip:08928856584@089.sip.arcor.de>;tag=84b3b10f

Via: SIP/2.0/UDP 192.168.2.101:5060;received=84.56.35.33;branch=z9hG4bK743c5c7d63ba5c6ec88ea16ea5a358ed383238;rport=5061
Reason: Q.850;cause=42;text="2"
Server: SSW/0.0.0
Contact: <sip:01796967019.iIiIiI.52521110.@82.82.16.8>
Content-Length: 0

The provide says that the service is not available. The Reason:
header gives an additional hint. It says Q.850; cause=42;text=2"

You are calling a mobile phone (0179.....), thus you are going from a
IP/SIP network into the classical phone network which is governed by
other (legacy) protocols, here SS#7 ISUP.

Q.850: is the ITU specification that describes the error cases for the
       legacy protocol
cause 42 arrording to this spec means: "Switching equipment congestion"

The cause seems strange: such a congestions could take place at the
interconnection points between the IP/SIP network and the legacy SS#7
networks or it could be that the interconnect point blocks this call
to the external network.

A big provider such as Vodafone should have big enough interconnection
points to handle the traffic.

It would be really interessting to see wireshark protocols of the various
softphones. Do you use the same account in all softphones (number/password)?

Pls see a question inline.

Regards,
Werner

Dear SIP Communicator developers,

I have had a chat with Lubomir Marinov this afternoon (he asked me to
post on this list as well) regarding a problem I encounter when using
SIP Communicator:
I am unable to establish any outgoing calls. Whenever I try to call a
contact/number, the "call window" opens, displays "connecting" for a
short period of time, but always changes to "failed". I am on Windows
Vista, the SIP provider in question is Vodafone Germany, formerly Arcor.
Interestingly, I am able to call my other accounts/numbers registered
with Vodafone (as my "landline" provider) but no "external"
providers/numbers. Receiving incoming calls works like a charm, no
matter where they originate from.

So you can make "outgoing calls" from SIP Communicator, but only to destinations
inside Vodafone?
Only outgoing calls to destinations external to the Vodafone network fail?

···

To: <sip:01796967019@089.sip.arcor.de>;tag=SD2a7i299-3e938a38-002b-01c6-0000-0000
Am 19.02.2010 17:24, schrieb Johannes Albert:

I have tried several other softphones (e. g. PhonerLite, Qutecom, ...)
with Vodafone as provider and they all worked well without any troubles.
Please find attached a logfile, which I retrieved from a "clean", i. e.
new installation of SIP Communicator after starting up the software,
entering my SIP account details and trying to call my cellphone
unsuccessfully. I hope this helps to shed some light on my problem, I'm
happy to provide any additional information if needed. (Lubomir has
pointed out the helpfulness of Wireshark dumps, but as I haven't used
this software before, I would need some more time to have a look at it...)

I appreciate your help, as I would love to use SIP Communicator as
multimessenger/voip-application in the future!
Thank you very much in advance,

Johannes Albert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

In addition to Werner's analysis (which by the way I find quite
impressive) I'd like to point out that SIP Communicator could have been
friendlier when reporting the error. Simply showing the "Failed" status
is hardly that revealing and we could have at least somehow indicated
the "Service Unavailable" string.

Could anyone please log an issue?

Emil

Werner Dittmann написа:

···

Hi Johannes,

looking at the SIP protocol of your call I see the following data (starting
at line 2545 in your log file):

SIP/2.0 503 Service Unavailable
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 2 INVITE
From: <sip:08928856584@089.sip.arcor.de>;tag=84b3b10f
To: <sip:01796967019@089.sip.arcor.de>;tag=SD2a7i299-3e938a38-002b-01c6-0000-0000
Via: SIP/2.0/UDP 192.168.2.101:5060;received=84.56.35.33;branch=z9hG4bK743c5c7d63ba5c6ec88ea16ea5a358ed383238;rport=5061
Reason: Q.850;cause=42;text="2"
Server: SSW/0.0.0
Contact: <sip:01796967019.iIiIiI.52521110.@82.82.16.8>
Content-Length: 0

The provide says that the service is not available. The Reason:
header gives an additional hint. It says Q.850; cause=42;text=2"

You are calling a mobile phone (0179.....), thus you are going from a
IP/SIP network into the classical phone network which is governed by
other (legacy) protocols, here SS#7 ISUP.

Q.850: is the ITU specification that describes the error cases for the
       legacy protocol
cause 42 arrording to this spec means: "Switching equipment congestion"

The cause seems strange: such a congestions could take place at the
interconnection points between the IP/SIP network and the legacy SS#7
networks or it could be that the interconnect point blocks this call
to the external network.

A big provider such as Vodafone should have big enough interconnection
points to handle the traffic.

It would be really interessting to see wireshark protocols of the various
softphones. Do you use the same account in all softphones (number/password)?

Pls see a question inline.

Regards,
Werner

Am 19.02.2010 17:24, schrieb Johannes Albert:

Dear SIP Communicator developers,

I have had a chat with Lubomir Marinov this afternoon (he asked me to
post on this list as well) regarding a problem I encounter when using
SIP Communicator:
I am unable to establish any outgoing calls. Whenever I try to call a
contact/number, the "call window" opens, displays "connecting" for a
short period of time, but always changes to "failed". I am on Windows
Vista, the SIP provider in question is Vodafone Germany, formerly Arcor.
Interestingly, I am able to call my other accounts/numbers registered
with Vodafone (as my "landline" provider) but no "external"
providers/numbers. Receiving incoming calls works like a charm, no
matter where they originate from.

So you can make "outgoing calls" from SIP Communicator, but only to destinations
inside Vodafone?
Only outgoing calls to destinations external to the Vodafone network fail?

I have tried several other softphones (e. g. PhonerLite, Qutecom, ...)
with Vodafone as provider and they all worked well without any troubles.
Please find attached a logfile, which I retrieved from a "clean", i. e.
new installation of SIP Communicator after starting up the software,
entering my SIP account details and trying to call my cellphone
unsuccessfully. I hope this helps to shed some light on my problem, I'm
happy to provide any additional information if needed. (Lubomir has
pointed out the helpfulness of Wireshark dumps, but as I haven't used
this software before, I would need some more time to have a look at it...)

I appreciate your help, as I would love to use SIP Communicator as
multimessenger/voip-application in the future!
Thank you very much in advance,

Johannes Albert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Dear Werner, Emil and others,

thank you for your fast replies and supporting efforts.

In response to your questions, Werner:

- Yes, I have successfully used the exact same account (number/password combination) with other softphones, on the same machine and in the same network setup.
- To clarify my statement about "successful outgoing calls": Vodafone serves as my landline provider. I have several phone numbers registered with them. All of them are, as far as I understand, separate sip accounts. One number is "automatically" assigned to my actual landline phone at home, one to my fax machine (this is done by connecting them to my router at home. Vodafone is providing specific router hardware, see www.dsl-easybox.de, but a AVM Fritz!Box or comparable routers should be able to do the job just as well). I have some more numbers/accounts, which I'm using with softphones (or, as in the case of SIP Communicator, I would like to use). Now, what I was trying to say is that I am able to establish an outgoing call to any of my other numbers using SIP Communicator (i. e. I can use SIP Communicator on my laptop in the living room to call my landline phone in the hallway). I can't establish any other outgoing calls, no matter if the potential recipients are in the Vodafone network or not (as a side note: Vodafone is also my cellphone carrier and the attempt to call failed, as you have seen - yet I have tried other providers as well with the same, negative results).

I hope this clarifies my problem and the setup I am working with. Feel free to ask if I missed any relevant aspects. Other than that, I am going to have a look at Wireshark now and will report later.

Kind regards,
Johannes

···

Am 19.02.2010 20:10, schrieb Werner Dittmann:

Hi Johannes,

looking at the SIP protocol of your call I see the following data (starting
at line 2545 in your log file):

SIP/2.0 503 Service Unavailable
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 2 INVITE
From:<sip:08928856584@089.sip.arcor.de>;tag=84b3b10f
To:<sip:01796967019@089.sip.arcor.de>;tag=SD2a7i299-3e938a38-002b-01c6-0000-0000
Via: SIP/2.0/UDP 192.168.2.101:5060;received=84.56.35.33;branch=z9hG4bK743c5c7d63ba5c6ec88ea16ea5a358ed383238;rport=5061
Reason: Q.850;cause=42;text="2"
Server: SSW/0.0.0
Contact:<sip:01796967019.iIiIiI.52521110.@82.82.16.8>
Content-Length: 0

The provide says that the service is not available. The Reason:
header gives an additional hint. It says Q.850; cause=42;text=2"

You are calling a mobile phone (0179.....), thus you are going from a
IP/SIP network into the classical phone network which is governed by
other (legacy) protocols, here SS#7 ISUP.

Q.850: is the ITU specification that describes the error cases for the
        legacy protocol
cause 42 arrording to this spec means: "Switching equipment congestion"

The cause seems strange: such a congestions could take place at the
interconnection points between the IP/SIP network and the legacy SS#7
networks or it could be that the interconnect point blocks this call
to the external network.

A big provider such as Vodafone should have big enough interconnection
points to handle the traffic.

It would be really interessting to see wireshark protocols of the various
softphones. Do you use the same account in all softphones (number/password)?

Pls see a question inline.

Regards,
Werner

Am 19.02.2010 17:24, schrieb Johannes Albert:

Dear SIP Communicator developers,

I have had a chat with Lubomir Marinov this afternoon (he asked me to
post on this list as well) regarding a problem I encounter when using
SIP Communicator:
I am unable to establish any outgoing calls. Whenever I try to call a
contact/number, the "call window" opens, displays "connecting" for a
short period of time, but always changes to "failed". I am on Windows
Vista, the SIP provider in question is Vodafone Germany, formerly Arcor.
Interestingly, I am able to call my other accounts/numbers registered
with Vodafone (as my "landline" provider) but no "external"
providers/numbers. Receiving incoming calls works like a charm, no
matter where they originate from.

So you can make "outgoing calls" from SIP Communicator, but only to destinations
inside Vodafone?
Only outgoing calls to destinations external to the Vodafone network fail?

I have tried several other softphones (e. g. PhonerLite, Qutecom, ...)
with Vodafone as provider and they all worked well without any troubles.
Please find attached a logfile, which I retrieved from a "clean", i. e.
new installation of SIP Communicator after starting up the software,
entering my SIP account details and trying to call my cellphone
unsuccessfully. I hope this helps to shed some light on my problem, I'm
happy to provide any additional information if needed. (Lubomir has
pointed out the helpfulness of Wireshark dumps, but as I haven't used
this software before, I would need some more time to have a look at it...)

I appreciate your help, as I would love to use SIP Communicator as
multimessenger/voip-application in the future!
Thank you very much in advance,

Johannes Albert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hello again,

dealing with Wireshark turned out to be easier than I thought. I hope the resulting dumps are helpful.
Please find attached three different logs, each referring to a different softphone. I started up the software in question, used the same sip account/number to sign in and tried to establish a call to my cellphone.
The softphones in use were as follows:
- PhonerLite - http://phonerlite.de/
- QuteCom - http://www.qutecom.org/
- SIP Communicator
It worked well with PhonerLite, but as an interesting twist to the story, it didn't work with QuteCom! I thought I'd be smart and downloaded the latest nightly build (http://trac.qutecom.org/wiki/Buildbot), but this didn't do any good. As with SIP Communicator, it didn't work anymore, although I had it working just a couple of days ago. To be honest, I am quite puzzled now, but maybe you can use the successful attempt with PhonerLite to figure out what went wrong.

As I haven't worked with Wireshark before, I can't tell, whether these dumps are actually useful. If I need to change any settings or such, please let me know!

Thanks & regards,
Johannes

phonerlite.pcap (140 KB)

qutecom_failed.pcap (349 KB)

sipcommunicator_failed.pcap (22.8 KB)

···

Am 20.02.2010 11:41, schrieb Johannes Albert:

Dear Werner, Emil and others,

thank you for your fast replies and supporting efforts.

In response to your questions, Werner:

- Yes, I have successfully used the exact same account (number/password
combination) with other softphones, on the same machine and in the same
network setup.
- To clarify my statement about "successful outgoing calls": Vodafone
serves as my landline provider. I have several phone numbers registered
with them. All of them are, as far as I understand, separate sip
accounts. One number is "automatically" assigned to my actual landline
phone at home, one to my fax machine (this is done by connecting them to
my router at home. Vodafone is providing specific router hardware, see
www.dsl-easybox.de, but a AVM Fritz!Box or comparable routers should be
able to do the job just as well). I have some more numbers/accounts,
which I'm using with softphones (or, as in the case of SIP Communicator,
I would like to use). Now, what I was trying to say is that I am able to
establish an outgoing call to any of my other numbers using SIP
Communicator (i. e. I can use SIP Communicator on my laptop in the
living room to call my landline phone in the hallway). I can't establish
any other outgoing calls, no matter if the potential recipients are in
the Vodafone network or not (as a side note: Vodafone is also my
cellphone carrier and the attempt to call failed, as you have seen - yet
I have tried other providers as well with the same, negative results).

I hope this clarifies my problem and the setup I am working with. Feel
free to ask if I missed any relevant aspects. Other than that, I am
going to have a look at Wireshark now and will report later.

Kind regards,
Johannes

Am 19.02.2010 20:10, schrieb Werner Dittmann:

Hi Johannes,

looking at the SIP protocol of your call I see the following data
(starting
at line 2545 in your log file):

SIP/2.0 503 Service Unavailable
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 2 INVITE
From:<sip:08928856584@089.sip.arcor.de>;tag=84b3b10f
To:<sip:01796967019@089.sip.arcor.de>;tag=SD2a7i299-3e938a38-002b-01c6-0000-0000

Via: SIP/2.0/UDP
192.168.2.101:5060;received=84.56.35.33;branch=z9hG4bK743c5c7d63ba5c6ec88ea16ea5a358ed383238;rport=5061

Reason: Q.850;cause=42;text="2"
Server: SSW/0.0.0
Contact:<sip:01796967019.iIiIiI.52521110.@82.82.16.8>
Content-Length: 0

The provide says that the service is not available. The Reason:
header gives an additional hint. It says Q.850; cause=42;text=2"

You are calling a mobile phone (0179.....), thus you are going from a
IP/SIP network into the classical phone network which is governed by
other (legacy) protocols, here SS#7 ISUP.

Q.850: is the ITU specification that describes the error cases for the
legacy protocol
cause 42 arrording to this spec means: "Switching equipment congestion"

The cause seems strange: such a congestions could take place at the
interconnection points between the IP/SIP network and the legacy SS#7
networks or it could be that the interconnect point blocks this call
to the external network.

A big provider such as Vodafone should have big enough interconnection
points to handle the traffic.

It would be really interessting to see wireshark protocols of the various
softphones. Do you use the same account in all softphones
(number/password)?

Pls see a question inline.

Regards,
Werner

Am 19.02.2010 17:24, schrieb Johannes Albert:

Dear SIP Communicator developers,

I have had a chat with Lubomir Marinov this afternoon (he asked me to
post on this list as well) regarding a problem I encounter when using
SIP Communicator:
I am unable to establish any outgoing calls. Whenever I try to call a
contact/number, the "call window" opens, displays "connecting" for a
short period of time, but always changes to "failed". I am on Windows
Vista, the SIP provider in question is Vodafone Germany, formerly Arcor.
Interestingly, I am able to call my other accounts/numbers registered
with Vodafone (as my "landline" provider) but no "external"
providers/numbers. Receiving incoming calls works like a charm, no
matter where they originate from.

So you can make "outgoing calls" from SIP Communicator, but only to
destinations
inside Vodafone?
Only outgoing calls to destinations external to the Vodafone network
fail?

I have tried several other softphones (e. g. PhonerLite, Qutecom, ...)
with Vodafone as provider and they all worked well without any troubles.
Please find attached a logfile, which I retrieved from a "clean", i. e.
new installation of SIP Communicator after starting up the software,
entering my SIP account details and trying to call my cellphone
unsuccessfully. I hope this helps to shed some light on my problem, I'm
happy to provide any additional information if needed. (Lubomir has
pointed out the helpfulness of Wireshark dumps, but as I haven't used
this software before, I would need some more time to have a look at
it...)

I appreciate your help, as I would love to use SIP Communicator as
multimessenger/voip-application in the future!
Thank you very much in advance,

Johannes Albert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Emil,

as our STUN expert :slight_smile: . I was analyzing the INVITE flow of Johannes'
outcall. The very first INVITE was rejected as usually requesting a
proxy authentication:

SIP/2.0 407 Proxy Authentication Required
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 1 INVITE

From: <sip:08928856584@089.sip.arcor.de>;tag=84b3b10f

Via: SIP/2.0/UDP 192.168.2.101:5060;received=84.56.35.33;branch=z9hG4bKf4cc9a64ebe3ea6af8b4f7f408457bf0383238;rport=5061
Server: SSW/0.0.0
Proxy-Authenticate: Digest realm="arcor.de",nonce="4b7eb4345db980a8541ae3dc56426c306377b8ac",algorithm=MD5
Contact: <sip:01796967019.iIiIiI.52521110.@82.82.16.8>
Content-Length: 0

Looking at this shows tha Johannes' Laptop uses 192.168.2.101 and his router
seems to have 84.56.35.33 . The SIP commincations works because of the routers
NAT function.

The authenticated INVITE looks like this:

INVITE sip:01796967019@089.sip.arcor.de SIP/2.0
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 2 INVITE

From: <sip:08928856584@089.sip.arcor.de>;tag=84b3b10f

Max-Forwards: 70
User-Agent: SIP Communicator1.0-alpha3-nightly.build.2402Windows Vista
Content-Type: application/sdp
Via: SIP/2.0/UDP 192.168.2.101:5060;branch=z9hG4bK743c5c7d63ba5c6ec88ea16ea5a358ed383238
Proxy-Authorization: Digest
username="08928856584",realm="arcor.de",nonce="4b7eb4345db980a8541ae3dc56426c306377b8ac",uri="sip:01796967019@089.sip.arcor.de",response="7a833c6b6e1dff6323fadfb46dc5d05b",algorithm=MD5
Content-Length: 656

v=0
o=08928856584 0 0 IN IP4 192.168.2.101
s=-
c=IN IP4 192.168.2.101
t=0 0
m=audio 5000 RTP/AVP 0 8 96 3 97 98 99 5 6 4 15
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/16000
a=rtpmap:99 speex/32000
a=rtpmap:5 DVI4/8000
a=rtpmap:6 DVI4/16000
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no;bitrate=6.3
a=rtpmap:15 G728/8000
a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
m=video 5002 RTP/AVP 100 34 26 31
a=recvonly
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=1
a=rtpmap:34 H263/90000
a=rtpmap:26 JPEG/90000
a=rtpmap:31 H261/90000

Which looks ok from the SIP perspective (NAT kicks in at the router) but not
from the SDP point of view. Here I still see 192.168.2.101 as IP address. Thus
the interconnect point sees the local IP address and refuses the service.

IMHO the problem is a STUN problem. Thus it's interessting to see if the other
SIP softclients use and apply STUN to fix the SDP data.

WDYT ?

Regards,
Werner

···

To: <sip:01796967019@089.sip.arcor.de>;tag=SD2a7i299-7c438d57-002b-01c6-0000-0000
To: <sip:01796967019@089.sip.arcor.de>
Contact: "08928856584" <sip:08928856584@192.168.2.101:5060;transport=udp;registering_acc=089_sip_arcor_de>

Am 20.02.2010 11:41, schrieb Johannes Albert:

Dear Werner, Emil and others,

thank you for your fast replies and supporting efforts.

In response to your questions, Werner:

- Yes, I have successfully used the exact same account (number/password
combination) with other softphones, on the same machine and in the same
network setup.
- To clarify my statement about "successful outgoing calls": Vodafone
serves as my landline provider. I have several phone numbers registered
with them. All of them are, as far as I understand, separate sip
accounts. One number is "automatically" assigned to my actual landline
phone at home, one to my fax machine (this is done by connecting them to
my router at home. Vodafone is providing specific router hardware, see
www.dsl-easybox.de, but a AVM Fritz!Box or comparable routers should be
able to do the job just as well). I have some more numbers/accounts,
which I'm using with softphones (or, as in the case of SIP Communicator,
I would like to use). Now, what I was trying to say is that I am able to
establish an outgoing call to any of my other numbers using SIP
Communicator (i. e. I can use SIP Communicator on my laptop in the
living room to call my landline phone in the hallway). I can't establish
any other outgoing calls, no matter if the potential recipients are in
the Vodafone network or not (as a side note: Vodafone is also my
cellphone carrier and the attempt to call failed, as you have seen - yet
I have tried other providers as well with the same, negative results).

I hope this clarifies my problem and the setup I am working with. Feel
free to ask if I missed any relevant aspects. Other than that, I am
going to have a look at Wireshark now and will report later.

Kind regards,
Johannes

Am 19.02.2010 20:10, schrieb Werner Dittmann:

Hi Johannes,

looking at the SIP protocol of your call I see the following data
(starting
at line 2545 in your log file):

SIP/2.0 503 Service Unavailable
Call-ID: 82eb17689af2b8dbf128d6143eb08def@0:0:0:0:0:0:0:0
CSeq: 2 INVITE
From:<sip:08928856584@089.sip.arcor.de>;tag=84b3b10f
To:<sip:01796967019@089.sip.arcor.de>;tag=SD2a7i299-3e938a38-002b-01c6-0000-0000

Via: SIP/2.0/UDP
192.168.2.101:5060;received=84.56.35.33;branch=z9hG4bK743c5c7d63ba5c6ec88ea16ea5a358ed383238;rport=5061

Reason: Q.850;cause=42;text="2"
Server: SSW/0.0.0
Contact:<sip:01796967019.iIiIiI.52521110.@82.82.16.8>
Content-Length: 0

The provide says that the service is not available. The Reason:
header gives an additional hint. It says Q.850; cause=42;text=2"

You are calling a mobile phone (0179.....), thus you are going from a
IP/SIP network into the classical phone network which is governed by
other (legacy) protocols, here SS#7 ISUP.

Q.850: is the ITU specification that describes the error cases for the
        legacy protocol
cause 42 arrording to this spec means: "Switching equipment congestion"

The cause seems strange: such a congestions could take place at the
interconnection points between the IP/SIP network and the legacy SS#7
networks or it could be that the interconnect point blocks this call
to the external network.

A big provider such as Vodafone should have big enough interconnection
points to handle the traffic.

It would be really interessting to see wireshark protocols of the various
softphones. Do you use the same account in all softphones
(number/password)?

Pls see a question inline.

Regards,
Werner

Am 19.02.2010 17:24, schrieb Johannes Albert:

Dear SIP Communicator developers,

I have had a chat with Lubomir Marinov this afternoon (he asked me to
post on this list as well) regarding a problem I encounter when using
SIP Communicator:
I am unable to establish any outgoing calls. Whenever I try to call a
contact/number, the "call window" opens, displays "connecting" for a
short period of time, but always changes to "failed". I am on Windows
Vista, the SIP provider in question is Vodafone Germany, formerly Arcor.
Interestingly, I am able to call my other accounts/numbers registered
with Vodafone (as my "landline" provider) but no "external"
providers/numbers. Receiving incoming calls works like a charm, no
matter where they originate from.

So you can make "outgoing calls" from SIP Communicator, but only to
destinations
inside Vodafone?
Only outgoing calls to destinations external to the Vodafone network
fail?

I have tried several other softphones (e. g. PhonerLite, Qutecom, ...)
with Vodafone as provider and they all worked well without any troubles.
Please find attached a logfile, which I retrieved from a "clean", i. e.
new installation of SIP Communicator after starting up the software,
entering my SIP account details and trying to call my cellphone
unsuccessfully. I hope this helps to shed some light on my problem, I'm
happy to provide any additional information if needed. (Lubomir has
pointed out the helpfulness of Wireshark dumps, but as I haven't used
this software before, I would need some more time to have a look at
it...)

I appreciate your help, as I would love to use SIP Communicator as
multimessenger/voip-application in the future!
Thank you very much in advance,

Johannes Albert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hello Emil,

I'm not entirely sure that's what you asked for but... I logged
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=788 as an
enhancement with the subject "Display call failure reason".

Best regards,
Lubo

···

On Fri, Feb 19, 2010 at 10:01 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

In addition to Werner's analysis (which by the way I find quite
impressive) I'd like to point out that SIP Communicator could have been
friendlier when reporting the error. Simply showing the "Failed" status
is hardly that revealing and we could have at least somehow indicated
the "Service Unavailable" string.

Could anyone please log an issue?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

The main difference between the successful call and the unsuccessful
calls:
- both clients offer video capabilities, SC as well as QuteCom, PhonerLite
  does not offer Video.

Looking at the successful call also shows that either the router (this
would be my first candidate) or some other network element fixes the
SDP data. IMHO the router uses a NAT/firewall combination that takes
care of the SDP data, similar to FTP in Linux firewall.

Johannes, can you try to switch off the video capabilities at SC using
"Werkzeuge->Einstellungen->Media" and switch off all Video codecs and
give it a try.

Thanks,
Werner

···

Am 20.02.2010 12:30, schrieb Johannes Albert:

Hello again,

dealing with Wireshark turned out to be easier than I thought. I hope
the resulting dumps are helpful.
Please find attached three different logs, each referring to a different
softphone. I started up the software in question, used the same sip
account/number to sign in and tried to establish a call to my cellphone.
The softphones in use were as follows:
- PhonerLite - http://phonerlite.de/
- QuteCom - http://www.qutecom.org/
- SIP Communicator
It worked well with PhonerLite, but as an interesting twist to the
story, it didn't work with QuteCom! I thought I'd be smart and
downloaded the latest nightly build
(http://trac.qutecom.org/wiki/Buildbot), but this didn't do any good. As
with SIP Communicator, it didn't work anymore, although I had it working
just a couple of days ago. To be honest, I am quite puzzled now, but
maybe you can use the successful attempt with PhonerLite to figure out
what went wrong.

As I haven't worked with Wireshark before, I can't tell, whether these
dumps are actually useful. If I need to change any settings or such,
please let me know!

Thanks & regards,
Johannes

<SNIP ---- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi Werner,

I switched off all the video codecs as instructed.
It still doesn't work, but now, as the call window states "Initiating call", a separate error window pops up, reading "An error occurred while sending invite request".
See attached Wireshark dump for details (hopefully).

Thank you for your time and effort,

Johannes

sipcommunicator_wo_video.pcap (17.2 KB)

···

Am 20.02.2010 13:24, schrieb Werner Dittmann:

The main difference between the successful call and the unsuccessful
calls:
- both clients offer video capabilities, SC as well as QuteCom, PhonerLite
   does not offer Video.

Looking at the successful call also shows that either the router (this
would be my first candidate) or some other network element fixes the
SDP data. IMHO the router uses a NAT/firewall combination that takes
care of the SDP data, similar to FTP in Linux firewall.

Johannes, can you try to switch off the video capabilities at SC using
"Werkzeuge->Einstellungen->Media" and switch off all Video codecs and
give it a try.

Thanks,
Werner

Am 20.02.2010 12:30, schrieb Johannes Albert:

Hello again,

dealing with Wireshark turned out to be easier than I thought. I hope
the resulting dumps are helpful.
Please find attached three different logs, each referring to a different
softphone. I started up the software in question, used the same sip
account/number to sign in and tried to establish a call to my cellphone.
The softphones in use were as follows:
- PhonerLite - http://phonerlite.de/
- QuteCom - http://www.qutecom.org/
- SIP Communicator
It worked well with PhonerLite, but as an interesting twist to the
story, it didn't work with QuteCom! I thought I'd be smart and
downloaded the latest nightly build
(http://trac.qutecom.org/wiki/Buildbot), but this didn't do any good. As
with SIP Communicator, it didn't work anymore, although I had it working
just a couple of days ago. To be honest, I am quite puzzled now, but
maybe you can use the successful attempt with PhonerLite to figure out
what went wrong.

As I haven't worked with Wireshark before, I can't tell, whether these
dumps are actually useful. If I need to change any settings or such,
please let me know!

Thanks& regards,
Johannes

<SNIP ---- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hey Johannes, Werner,

Disabling all codecs was currently resulting in the call initialization
problem that Johannes reported. Personally I was doing this by selecting
the "No Device" option from the device combo.

I've just fixed this however (r6784 and build.2403 which should come in
a few minutes) so you can either upgrade with your current config or use
the "No Device" option. (You make have to restart SC if you go for the
latter).

As per your connection problem, I think that Werner's suggestion that
the video stream might be the reason is indeed the most likely culprit.
Both Qutecom and SC have it and your other trace doesn't. Besides I
believe I've already seen 503-s for that kind of problem elsewhere.

I really don't think use of STUN and the NATed address have anything to
do with this. First, because all phones are sending their NATed
addresses and second because, to my knowledge, this has never really
been a problem for anyone else but ekiga.net.

Hope this helps,
Emil

Johannes Albert написа:

···

Hi Werner,

I switched off all the video codecs as instructed.
It still doesn't work, but now, as the call window states "Initiating
call", a separate error window pops up, reading "An error occurred while
sending invite request".
See attached Wireshark dump for details (hopefully).

Thank you for your time and effort,

Johannes

Am 20.02.2010 13:24, schrieb Werner Dittmann:

The main difference between the successful call and the unsuccessful
calls:
- both clients offer video capabilities, SC as well as QuteCom, PhonerLite
   does not offer Video.

Looking at the successful call also shows that either the router (this
would be my first candidate) or some other network element fixes the
SDP data. IMHO the router uses a NAT/firewall combination that takes
care of the SDP data, similar to FTP in Linux firewall.

Johannes, can you try to switch off the video capabilities at SC using
"Werkzeuge->Einstellungen->Media" and switch off all Video codecs and
give it a try.

Thanks,
Werner

Am 20.02.2010 12:30, schrieb Johannes Albert:

Hello again,

dealing with Wireshark turned out to be easier than I thought. I hope
the resulting dumps are helpful.
Please find attached three different logs, each referring to a different
softphone. I started up the software in question, used the same sip
account/number to sign in and tried to establish a call to my cellphone.
The softphones in use were as follows:
- PhonerLite - http://phonerlite.de/
- QuteCom - http://www.qutecom.org/
- SIP Communicator
It worked well with PhonerLite, but as an interesting twist to the
story, it didn't work with QuteCom! I thought I'd be smart and
downloaded the latest nightly build
(http://trac.qutecom.org/wiki/Buildbot), but this didn't do any good. As
with SIP Communicator, it didn't work anymore, although I had it working
just a couple of days ago. To be honest, I am quite puzzled now, but
maybe you can use the successful attempt with PhonerLite to figure out
what went wrong.

As I haven't worked with Wireshark before, I can't tell, whether these
dumps are actually useful. If I need to change any settings or such,
please let me know!

Thanks& regards,
Johannes

<SNIP ---- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Dear Emil and Werner,

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None".

I have had the same experience as described by Werner (missing <No

option in the list of video sources), but in the meantime I have

realized, that <No Device> as the last entry in the list is covered by the preview window (I am on a 13.3" screen with a 1366x768 desktop resolution) and therefore can't be selected with the mouse. It is possible to select it with the arrow keys, though. Maybe you can have the list of devices be rendered in front of the preview window or arrange these elements differently in order to fix this issue.

The latest build resolved the problem with the separate error message reported earlier (thanks, Emil), but unfortunately my original issue is still persisting.
Whether I disable the video source by choosing <No Device> in the list of video devices or switch of all related codecs (or do both), I still cannot place any outgoing calls. The status message in the call window switches from "Initiating Call" via "Connecting" to "Failed".

Please see attached Wireshark dump for possible details.

Cheers,
Johannes

sipcommunicator_wo_video_2403.pcap (38.5 KB)

···

Am 20.02.2010 15:00, schrieb Emil Ivov:

Hey Johannes, Werner,

Disabling all codecs was currently resulting in the call initialization
problem that Johannes reported. Personally I was doing this by selecting
the "No Device" option from the device combo.

I've just fixed this however (r6784 and build.2403 which should come in
a few minutes) so you can either upgrade with your current config or use
the "No Device" option. (You make have to restart SC if you go for the
latter).

As per your connection problem, I think that Werner's suggestion that
the video stream might be the reason is indeed the most likely culprit.
Both Qutecom and SC have it and your other trace doesn't. Besides I
believe I've already seen 503-s for that kind of problem elsewhere.

I really don't think use of STUN and the NATed address have anything to
do with this. First, because all phones are sending their NATed
addresses and second because, to my knowledge, this has never really
been a problem for anyone else but ekiga.net.

Hope this helps,
Emil

Johannes Albert написа:

Hi Werner,

I switched off all the video codecs as instructed.
It still doesn't work, but now, as the call window states "Initiating
call", a separate error window pops up, reading "An error occurred while
sending invite request".
See attached Wireshark dump for details (hopefully).

Thank you for your time and effort,

Johannes

Am 20.02.2010 13:24, schrieb Werner Dittmann:

The main difference between the successful call and the unsuccessful
calls:
- both clients offer video capabilities, SC as well as QuteCom, PhonerLite
    does not offer Video.

Looking at the successful call also shows that either the router (this
would be my first candidate) or some other network element fixes the
SDP data. IMHO the router uses a NAT/firewall combination that takes
care of the SDP data, similar to FTP in Linux firewall.

Johannes, can you try to switch off the video capabilities at SC using
"Werkzeuge->Einstellungen->Media" and switch off all Video codecs and
give it a try.

Thanks,
Werner

Am 20.02.2010 12:30, schrieb Johannes Albert:

Hello again,

dealing with Wireshark turned out to be easier than I thought. I hope
the resulting dumps are helpful.
Please find attached three different logs, each referring to a different
softphone. I started up the software in question, used the same sip
account/number to sign in and tried to establish a call to my cellphone.
The softphones in use were as follows:
- PhonerLite - http://phonerlite.de/
- QuteCom - http://www.qutecom.org/
- SIP Communicator
It worked well with PhonerLite, but as an interesting twist to the
story, it didn't work with QuteCom! I thought I'd be smart and
downloaded the latest nightly build
(http://trac.qutecom.org/wiki/Buildbot), but this didn't do any good. As
with SIP Communicator, it didn't work anymore, although I had it working
just a couple of days ago. To be honest, I am quite puzzled now, but
maybe you can use the successful attempt with PhonerLite to figure out
what went wrong.

As I haven't worked with Wireshark before, I can't tell, whether these
dumps are actually useful. If I need to change any settings or such,
please let me know!

Thanks& regards,
Johannes

<SNIP ---- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hello once again,

it's probably not the best style to respond to my own posting, but I'm pretty sure I have found the culprit: it seems to be the G723/8000 audio codec (and supposedly the G722/8000, which is used by QuteCom).
After I still had 415-s in the Wireshark dump after turning off video support, I started testing all the audio codecs separately and suddenly calling worked well until I got to the aforementioned one.
I have no clue if this is a problem with its implementation or an issue on my (provider's) side, but I am glad I got down to it. I assume it's no problem to switch off this specific codec in order to have SIP Communicator work flawlessly.

Thanks for all your support in the past couple of days, I hope I didn't keep any of you from paying attention to more important things. :wink: Keep up the great work!

Thanks a lot,
Johannes

···

Am 20.02.2010 15:47, schrieb Johannes Albert:

Dear Emil and Werner,

When trying to set the media configuration the preview window shows
my desktop. Similar to the audio interface the video interface
seems to offer a selection to switch between video sources.
However, it seems that it does not offer "None".

I have had the same experience as described by Werner (missing <No
> option in the list of video sources), but in the meantime I have
realized, that <No Device> as the last entry in the list is covered by
the preview window (I am on a 13.3" screen with a 1366x768 desktop
resolution) and therefore can't be selected with the mouse. It is
possible to select it with the arrow keys, though. Maybe you can have
the list of devices be rendered in front of the preview window or
arrange these elements differently in order to fix this issue.

The latest build resolved the problem with the separate error message
reported earlier (thanks, Emil), but unfortunately my original issue is
still persisting.
Whether I disable the video source by choosing <No Device> in the list
of video devices or switch of all related codecs (or do both), I still
cannot place any outgoing calls. The status message in the call window
switches from "Initiating Call" via "Connecting" to "Failed".

Please see attached Wireshark dump for possible details.

Cheers,
Johannes

Am 20.02.2010 15:00, schrieb Emil Ivov:

Hey Johannes, Werner,

Disabling all codecs was currently resulting in the call initialization
problem that Johannes reported. Personally I was doing this by selecting
the "No Device" option from the device combo.

I've just fixed this however (r6784 and build.2403 which should come in
a few minutes) so you can either upgrade with your current config or use
the "No Device" option. (You make have to restart SC if you go for the
latter).

As per your connection problem, I think that Werner's suggestion that
the video stream might be the reason is indeed the most likely culprit.
Both Qutecom and SC have it and your other trace doesn't. Besides I
believe I've already seen 503-s for that kind of problem elsewhere.

I really don't think use of STUN and the NATed address have anything to
do with this. First, because all phones are sending their NATed
addresses and second because, to my knowledge, this has never really
been a problem for anyone else but ekiga.net.

Hope this helps,
Emil

Johannes Albert написа:

Hi Werner,

I switched off all the video codecs as instructed.
It still doesn't work, but now, as the call window states "Initiating
call", a separate error window pops up, reading "An error occurred while
sending invite request".
See attached Wireshark dump for details (hopefully).

Thank you for your time and effort,

Johannes

Am 20.02.2010 13:24, schrieb Werner Dittmann:

The main difference between the successful call and the unsuccessful
calls:
- both clients offer video capabilities, SC as well as QuteCom,
PhonerLite
does not offer Video.

Looking at the successful call also shows that either the router (this
would be my first candidate) or some other network element fixes the
SDP data. IMHO the router uses a NAT/firewall combination that takes
care of the SDP data, similar to FTP in Linux firewall.

Johannes, can you try to switch off the video capabilities at SC using
"Werkzeuge->Einstellungen->Media" and switch off all Video codecs and
give it a try.

Thanks,
Werner

Am 20.02.2010 12:30, schrieb Johannes Albert:

Hello again,

dealing with Wireshark turned out to be easier than I thought. I hope
the resulting dumps are helpful.
Please find attached three different logs, each referring to a
different
softphone. I started up the software in question, used the same sip
account/number to sign in and tried to establish a call to my
cellphone.
The softphones in use were as follows:
- PhonerLite - http://phonerlite.de/
- QuteCom - http://www.qutecom.org/
- SIP Communicator
It worked well with PhonerLite, but as an interesting twist to the
story, it didn't work with QuteCom! I thought I'd be smart and
downloaded the latest nightly build
(http://trac.qutecom.org/wiki/Buildbot), but this didn't do any
good. As
with SIP Communicator, it didn't work anymore, although I had it
working
just a couple of days ago. To be honest, I am quite puzzled now, but
maybe you can use the successful attempt with PhonerLite to figure out
what went wrong.

As I haven't worked with Wireshark before, I can't tell, whether these
dumps are actually useful. If I need to change any settings or such,
please let me know!

Thanks& regards,
Johannes

<SNIP ---- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net