0
votes

For a toy project I want to find out if a mobile phone is connected to gsm or not. So I thought "Okay, let's use my local sip provider and see".

But in both cases, the thing goes like this:

  1. I send an INVITE
  2. 0 s: I get a 100 Trying
  3. 5 s: I get a 183 Session description
  4. I get an audio stream, in the one case with the ringing, in the other case with a "The person you are calling is…"

If I wait long enough (~ 40 s), I get a more appropiate status code like 180 Ringing.

Audio analysis is not an option, really.

Any hints on where to go now?

(I used twinkle for testing and a local german sip-provider.)

1
In the case of "The person you are calling is...", if you wait long enough you should eventually get an error back. This will be your only indication that the call did not complete successfully.Celada
@Celada - Yes, as I said, if I wait 40 sec+, I get something more useful. In the "The person ..." case, I get some 484 Incomplete address (strange enough). But I don't want to wait that long. By that time, someone will have picked up the phone, answered the call and wasted some money.Elrond
Sorry, you have to wait. This is a chronic problem in telephone networks: it strikes with SS7 and ISDN too, not just with SIP. On trunks that are configured to emit a "friendly" error message, you don't get the call clearing status until after the "friendly" message is finished.Celada
1) This sounds a bit like an "answer"? (not the one I want to hear, clearly). You might want to post as an answer? Do you have some references? 2) Does that mean I can get (read: buy) a specific "trunk" that gives me better signaling, possibly without friendly messages?Elrond

1 Answers

1
votes

This issue is endemic in the way telephone networks work, and is not specific to SIP or IP. It's why, when you place a call to another country and the number is busy, you might sometimes hear your local country's busy tone, or you might hear a different busy tone that comes from the other country. In the latter case you cannot detect except by audio analysis, what the problem is. In SS7 and ISDN we speak of Q.931 cause codes instead of SIP error codes, but the principle is the same.

There's an argument to be made for configuring telephone systems to emit status codes instead of audio error messages. For callers using normal phones, the originating switch (the one closest to the caller) can then map that code to the appropriate spoken error message or audio tone. That way, when the call is being placed by software rather than by a person, the software can have access to the actual error code right away.

On the other hand you can also argue for having the remote switch (the one nearest the destination or the one that encounters the problem) speak its own error message. That switch knows best what the actual problem is. For example, a mobile operator can emit a spoken error message saying that the mobile phone you are trying to call is currently out of range. There is no Q.931 code (or SIP error code for that matter) with that meaning. It could return 27=Destination out of order?? Or 35=Destination unattainable?? Both of those codes are so esoteric, who knows what error message the local switch would translate them to (in practice: probably just a reorder tone, which is really user-unfriendly to a human caller). And when you try to map Q.931 cause codes to SIP error codes back and forth, even more information is lost because the codes really don't match up well at all. It's likely to be a much better user experience for the caller if the remote switch just plays back an informative, appropriate, recording which describes the problem.

Since there is this dilemma (arguments on both sides), we can conclude that this will not likely be resolved by completely standardizing on one way or ther other way anytime soon.

Anyway, sometimes this is configurable: your SIP provider may be able to configure your trunk for coded errors instead of recorded messages. If they offer this (some do), it's worth a try to set this option. But results will vary: this option only affects its local behaviour. In general if you want immediately call clearing with cause code and are instead getting a recorded error message from the other end, you will not be able to do anything about it, because the switch that makes the decision on which way it's going to respond is the remote one.

When using the audio message method, a proper Q.931 cause code or SIP error code usually comes eventually (after the recording is finished), but as you point out, it's probably too late by then.