outbound ring tone

Started by coldhammer, August 03, 2015, 06:07:06 PM

Previous topic - Next topic

coldhammer

im not sure what to call this so i cant really search for it.

when i dial out using my GV account instead of hearign a typical ring pattern like you might with a regular phone line i hear a long beep for each set of rings.

is there a setting to change this sound to something else like a standard ring pattern?

CoalMinerRetired

That sounds like the ring back signals, and are controlled by the other end, meaning there's nothing you can do to alter it. 

I'll leave the door open a bit on this to say some VOiP phone calls give a signal before the called party's phone reports ringing, and that may be what you are hearing. However on all my GV calls I immediately hear the ringing, with a different cadence/pattern for calls to the UK and Australia, for example.

It's known as Ring Back, or Ring Back Cadence or Ring Back signal or tone.  Look up the international standards for this, ITU Ring Back signals. Different countries have different signals/patterns/cadences, and it can be interesting to hear the sounds you're not always used to, Italy and some Eastern European countries have interesting patterns. Youtube has some examples.

coldhammer

I think this is specific to the Obi.

Utilizing GV without goign through the obi results in a normal sounding ring tone. The issue only arises when trying to route GV calls through the obi.

CoalMinerRetired

It's a worldwide standard that the ringing you hear when placing a call is generated by the called party's equipment, not by the calling party's equipment.  I don't believe there is any mechanism, in an OBi or otherwise, that intercepts a call being setup and generates a tone, a beep or any signal.

My guess is what you are hearing is something happening between your dialing and when GV is able to send the ring back tones, or for reasons unknown there is significant latency between when you finish dialing a call and when your OBi gets the ring back signals. 

A few things to try, see if any make a difference:
Do you press # at the end of each call you dial? That makes any dialed numbers process immediately.
In the OBi only, change the DNS servers to use Google's, 8.8.8.8 & 8.8.4.4.  Or better yet use this grc.com tool to test the your latency to different DNS servers: https://www.grc.com/dns/benchmark.htm.

You really want the above test from your OBi, but you can't do that. Which leads to do you have any QoS settings enabled in your router?

When you dial a GV # elsewhere and do not hear these tones, how are you placing that call, on a cell phone? Via the Call Phone icon in Gmail? Something else?


coldhammer

its not a latency issue. all calls were made to the same three test numbers.

gigaset > obi202 via ip > gv > test number = long beep instead of ringing sound.
gigaset > obi202 via ph1 > gv > test number = normal ring tone
gigaset > obi202 via ip > alternate voip service > test number = normal ring tone
gigaset > obi202 via ip > obiLine > test number = normal ring tone

the above tests show that:
the gigaset is not the issue.
gv is not the issue
the issue only presents itself when routing an ip call through the obi to gv. This leads me to believe there is some sort of setting within the obi that is generating this beep sound instead of the standard ring tone for outgoing calls.

drgeoff

#5
Quote from: CoalMinerRetired on August 05, 2015, 06:23:38 AM
It's a worldwide standard that the ringing you hear when placing a call is generated by the called party's equipment, not by the calling party's equipment.  I don't believe there is any mechanism, in an OBi or otherwise, that intercepts a call being setup and generates a tone, a beep or any signal.
No, that  is not totally correct.

Yes, it is the way that pure POTS/PSTN calls generally work. But it may not apply when VoIP is involved. For example when a call is purely SIP,  the ringing tone heard by the caller is generated in the caller's terminal when the SIP 180 'Ringing' message is received. See for example Fig 1 at http://pbx-solutions.blogspot.co.uk/2010/06/overview-about-session-initiation.html.  That message comes in the signalling channel,  there is no audio path existing at that point in time.

ianobi

#6
I'll see if I can make this even more complicated  :)

Where the ringback tone is generated depends on "early media" and how the OBi device handles that. "Early media" is any audio and/or video that is sent in either direction before the call is actually answered. This might be an information message or a tone etc.

With regard to SIP the "180 Ringing" message is sent from the callee SIP equipment back to the caller SIP equipment (OBi in this case) to indicate that the callee is actually being called. The OBi device handles this as follows:
1. If "early media" has been established and an RTP path has been established between caller and callee before the "200 OK" message (call answered), then the OBi will ignore the "180 Ringing" message and pass the early media to the caller. So a voip provider may send its own ringback tone via early media.
2. If no "early media" has been detected by the OBi, then when it receives the "180 Ringing" message from the callee it will generate its own ringback tone locally and send that to the caller.

In my own setup I have tested one provider (sipgate) that uses early media to supply ringback tone, so case 1 applies. Another provider (sip2sip) does not provide early media, so case 2 applies.

Of course, GV uses XMPP not SIP, but I believe that XMPP behaves the same with regard to early media as SIP. Also, I believe that GV does not provide early media, so it is likely that it's the OBi providing the ringback tone locally. This could be proved by changing the relevant tone pattern in the OBi. However, I would say that I am very much NOT an expert when it comes to GV, so maybe our resident GV expert would like to comment on that.

I trust that's helped anyone who managed to stay awake to the end of this post   :D

Edit: There is another scenario where a voip provider who wishes to use "early media" does not send the "180 Ringing message" back to the caller at all, but instead sends a "183 Session Progress" message which contains all the information (connection ip address, codecs to use etc) back to the caller SIP equipment (OBi in our case). This enables an audio channel to be opened for sending tones, IVR announcements etc before the "200 OK" message confirms that the call is connected and call charging can begin.

CoalMinerRetired

Quote from: drgeoff on August 06, 2015, 02:36:49 AM
Quote from: CoalMinerRetired on August 05, 2015, 06:23:38 AM
It's a worldwide standard that the ringing you hear when placing a call is generated by the called party's equipment, not by the calling party's equipment.  I don't believe there is any mechanism, in an OBi or otherwise, that intercepts a call being setup and generates a tone, a beep or any signal.
No, that  is not totally correct.

Yes, it is the way that pure POTS/PSTN calls generally work. But it may not apply when VoIP is involved. For example when a call is purely SIP,  the ringing tone heard by the caller is generated in the caller's terminal when the SIP 180 'Ringing' message is received. See for example Fig 1 at http://pbx-solutions.blogspot.co.uk/2010/06/overview-about-session-initiation.html.  That message comes in the signalling channel,  there is no audio path existing at that point in time.
Thanks. My understanding is from 20 years ago (all landlines).  However, what you said and what Inaobi added sums up to: the ITU standard doesn't apply to sip to sip calls, and for sip to sip in some cases it may not.

So I think there's still a mystery, because GV is not SIP, and on top of that GV does not support early media unless something has changed very recently.

I'll also add I see no OBi settings (202/110/100) that hint at controlling this, however since it's happening and it's never been mentioned here might mean it's one of those unexplained 'magic number configuration fields' that are right in front of us.

azrobert

Quote from: ianobi on August 06, 2015, 03:28:07 AM
2. If no "early media" has been detected by the OBi, then when it receives the "180 Ringing" message from the callee it will generate its own ringback tone locally and send that to the caller.
I set the following:
Tone Settings -> Tone Profile A -> Ringback Tone -> Tone Pattern:
480-18,620-18;10;(.25+.25)  (Fast Busy)

I called a GV number and heard a fast busy tone instead of the ringback tone. I think this confirms what ianobi posted above.

drgeoff

@ianobi
I've never had a need to understand the "early media" stuff so I've never investigated it. Do you know for a fact that Sipgate UK use it or is it a conclusion you have come to?

I ask because most calls placed via Sipgate UK are not SIP end to end. In a pure SIP to SIP call the audio flows directly between the two endpoints. However many ITSPs do not work that way but remain "in circuit".  I suspect that there is SIP between your OBi and Sipgate and then there is POTS/PSTN/cellular or another SIP between Sipgate UK and the callee. Thus it appears (to me) that tones you hear could come from Sipgate equipment, or anywhere else on the route to the callee. And that would be possible without "early media" between Sipgate and your OBi; merely that the "call" from your OBi to Sipgate is answered immediately and any call progress tones (Sipgate to callee) you hear are coming to the OBi as audio in the ordinary way.

I'm not saying you are wrong and I am correct. I'm just interested in knowing exactly what is going on and whether you or anyone else has hard evidence which clarifies matters.

ianobi

#10
@ drgeoff

Attached is a Wireshark trace of a call I have just made from my OBi1032 using sipgate to my mobile. I did not answer the call. Times show:
1643:17 - RTP established in both directions (early media).
I now hear ring back tone from PSTN / cellular.
1643:32 - CANCEL - when I hung up from the OBi1032.

In this situation the sipgate servers have no way of knowing for sure what the POTS/PSTN/cellular end point will return in way of audio. It might be a ring back tone, busy tone, announcements ("this number does not exist" etc), IVR announcements and so on. In this situation the voip provider needs to feed back the audio from the callee equipment to the caller before the call is answered or not by the called party. Actual speech cannot take place until the "200 OK" message is passed from sipgate back to the OBi. This will be done if the sipgate server detects a definite answer signal from the callee equipment, in this example that never happens.

This is a case where the "183 Session Progress" message from sipgate to the OBi contains all the information that the OBi needs to establish the RTP link. Sipgate received the equivalent information from the OBi in the original "INVITE" message.

One good reason for using early media in this way is to ensure that users are not charged for a call where they simply receive busy tone or some announcement.



drgeoff

@ianobi
Thanks for that.

I've had a look at https://tools.ietf.org/html/rfc3960. One needs to be in the "really determined" category to enjoy reading such RFCs.  :)

ianobi

@drgeoff

QuoteI've had a look at https://tools.ietf.org/html/rfc3960. One needs to be in the "really determined" category to enjoy reading such RFCs.

Very true. My example was a simple one. If you add in call forking, calls being routed via many SIP hops, but the RTP being direct etc, etc ... just now I'm more interested in the cricket   :D

ianobi

Let's not forget the OP in all this discussion about "early media".

The GV situation is well described here by SteveInWA:
http://www.obitalk.com/forum/index.php?topic=9269.msg61383#msg61383

azrobert's test in Reply #8 proves that the ring back tone is being provided locally by the OBi. The OP needs to have a look in the relevant Tone Profile. There is a setting for Ringback Tone, which I would think would be the one used for any outgoing GV calls.

SteveInWA

Ian, great job diving into early media, and thanks for linking to my posts.

I do have to chuckle, though, about how many times somebody comes to this forum with some really unusual configuration to accomplish some goal, determined to do it his way, even if there's a better, simpler, more technically-elegant solution.  Then, a lengthy discussion ensues as to how to make the poster's weird setup work, rather than how to accomplish the overall goal in a better way.  The best recent example of this was the guy who wanted to turn a decommissioned cell phone into a secret recording device, via his OBi.

We already went down this "forward inbound calls to my OB'i and out again to my cell phone" route with another poster.

If it were up to me, I'd control the call routing from the Google Voice user interface, which is designed precisely for this purpose, instead of routing calls inside the OBi.  Removing some of that complexity and restoring defaults as appropriate, would probably fix this issue.

Aside from that, there's the "flow chart":

Is the beep really hurting your ears?

Is it preventing you from determining if the call is ringing or not?

Did you mess with the ring tone settings and create this issue yourself?

If no to all questions, fuggedaboudit.

NoelB

#15
Quote from: ianobi on August 06, 2015, 09:27:24 AM
@ drgeoff

Attached is a Wireshark trace of a call I have just made from my OBi1032 using sipgate to my mobile. I did not answer the call. Times show:
1643:17 - RTP established in both directions (early media).
I now hear ring back tone.

I can only comment from an Au viewpoint ( and just forget the cricket  :(
Most of what you describe is the same here but the only time we see a 180 ringing is when a local sip client sends it in response to an incoming call to alert the sip proxy that the invite has been received. All the vsps here use a 183 Session Progress to initiate early media and only on a rare occasion have I seen an incoming 180 ringing --never both. A 180 will have been generated by the remote UA but not passed on by the sip proxy if a 183 has been sent. The 183 is generated at the sip/PSTN gateway and sent via the sip proxy server to the sip client and 2 way early media commences. This is also important as it gives the sip media server  a chance to adjust the rtp destination port if it has been fooled by the clients napt
In your wireshark ladder map I cant understand how you can hear ring back tone unless our definition is different to yours . With the 183 and early media we would hear the actual pstn ring tone or engaged tone not a generated ring back tone.

ianobi

@ NoelB

QuoteI cant understand how you can hear ring back tone unless our definition is different to yours . With the 183 and early media we would hear the actual pstn ring tone or engaged tone not a generated ring back tone.

I agree. That's exactly what I meant. The early media allows the tones from POTS / PSTN / cellular to be routed back through the sip proxy to sip client to caller. I have modified my post to make that more clear.

Your good description of how early media works using 183 Session Progress by itsps / vsps is the most usual way of doing things. However, if you follow the link provided by drgeoff above you will see that the rfc standard does describe how user clients (such as OBi devices) should react to receiving 180 ringing messages. I think we are pretty much in agreement here!

I promise not to mention the cricket more than once a day for the next few weeks   :D