Cannot get any of the samples to respond to incoming calls

[pointoneepos]

Hi,

I am trying to write code to monitor a SIP line and parse the caller contact info only. I don't need to answer the call or extract any audio, just parse the header. I have been successful in getting a mash up of the samples to register with the SIP service and can place calls, but I cannot seem to get it to fire incoming call events when registered with voiptalk.org. Other softphones (eg. 3cx) respond to incoming calls. Any suggestions?

(As mentioned I am using a commercial web-based SIP service, not just running this on a local network)

Many thanks
Nick

[sipsorcery]

Most likely it's a NAT issue.

Try using WireShark or a similar tool to compare the Contact header on the REGISTER request sent by your app and a softphone.

[pointoneepos]

Thanks for the reply. I see nothing in Wireshark from the IP of voiptalk.org on an inbound call, but I do see traffic to them when placing a call. All traffic is allowed outbound through my Windows firewall and our Draytek router - I believe that SIP traffic is automatically allowed to traverse back through the router’s firewall in response to an outgoing session (?) The 3cx softphone works fine (inbound and out) connected to the same SIP service. Is there anything else you could recommend I look at? Many thanks Nick Williams CTO

[pointoneepos]

Yup – was SIP ALG – not sure how the other Softphone dealt with it…. Thanks anyway Nick Williams CTO

[sipsorcery]

Yup – was SIP ALG – not sure how the other Softphone dealt with it….

Most likely because softphone apps will use STUN to determine the public IPv4 address and place that in the REGISTER Contact. ALG's will mostly leave public IP addresses alone.

The sipsorcery library does have STUN functionality but it's not hooked up by default. Using STUN for setting the REGISTER Contact can actually cause other problems if you are operating fully on a private network. In the absence of a public IPv4 address the REGISTER request from sipsorcery will have a private IPv4 address in the Contact header and the ALG was probably mangling it. SIP ALG's have always been a disaster.

[pointoneepos]

Aaron Many thanks for your help. One last question – I have access to your CallEnded event, but I wonder if it is possible to distinguish (in code) between these two separate call end possibilities: 1. Caller gave up and put the phone down 2. Another user (on a parallel line in the hunt group) answered the call ?? Many thanks Nick Nick Williams CTO

[sipsorcery]

If you're using the SIPUserAgent from the sipsorcery library it doesn't support forking so it can only ever ring a single destination at any one time. Forking isn't hard it would be a matter of creating a SIPUserAgent for each SIP address and calling them all simultaneously. You'd know which one answered by the first one to fire the ClientCallAnswered event.

If you are finding that a single SIPUserAgent is resulting in multiple devices ringing it means the forking is occurring from the SIP server you're calling. In that case it's unlikely you'll know which device answered as the SIP Server is probably acting as a B2BUA and none of the SIP headers from the device make it back to the caller.

[pointoneepos]

Ahh sorry, my bad in describing… The code I’m prototyping will be a quasi-softphone but I’m only interested in signalling, not media.. I’m not starting or answering any calls from this code – This code will be set to “ring” in tandem with x number of real hardphones. That way I can pull call stats, etc. Therefore, I can see when a ringing (inbound) call has stopped/ended, but would be good to know if it was answered by a hardphone, or whether the caller gave up. Does that make more sense? Thanks again for your prompt reply! Nick

[sipsorcery]

Understood. The answer is theoretically yes (there are hundreds of SIP RFC's after all) but in practice no.

I'm assuming you can't see the SIP traffic sent to the other devices otherwise you could capture it and determine who answered. The only other option that comes to mind is the SIP Dialog Event Package but even in the unlikely event it's supported by the SIP server I don't think it includes much more that the dialog state and hence wouldn't tell you which device answered the call. The SIP Presence Event Package is probably the same. It would notify you when the status of a particular SIP address changed but is unlikely to provide information about which device for an address changed. The SIP event packages can be customised so in theory could be extended to provide extra info but if you don't control the server that will be very difficult.

There could also be some other SIP mechanism I haven't thought of. As mentioned above there are a huge number of SIP standards that cover just about everything.