Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: Local ringback on SIP 180 from Broadsoft media server vs
phone generated RBT (John Botha)
2. Re: Strange calling patterns (PE)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Nov 2012 07:59:44 +0200
From: John Botha <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [VoiceOps] Local ringback on SIP 180 from Broadsoft media
server vs phone generated RBT
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have always been under the impression PRACK is for transmission over
unreliable media, i.e open internet. Since most of our customer base is SIP
trunking and registered devices for Broadsoft hosted PBX, where the last
mile is QoS controlled for signaling and media, so PRACK should not be
required in both scenarios.
Most ringback scenarios have 180 without SDP arriving back at the caller,
signaling local RBT for the endpoint is required, whether the RBT is
generated by a device closer to the endpoint or the endpoint itself is the
discussion.
Broadsoft DMS has profiles for the phones that gets downloaded to them with
user logon details and other options like the option to generate local RBT
probably via .wav file or similar.
The concern I have is that if the media comes from a centralized source like
a BSFT media server, issues on the MS will have customers stranded with
garbled/no RBT/wrong RBT. My employer due to a legacy TDM background prefers
non-endpoint RBT generated (he would, seeing that in TDM the remote side or
closest network exit to the phone generates the RBT).
I have always taken it for granted that best common practice is for the
device to generate its own ringtone in a SIP environment. I am now forced
to question this logic, as the argument is that in TDM ringback has no
issues, but can be problematic in SIP.
From: John S. Robinson [mailto:[email protected]]
Sent: Tuesday, November 06, 2012 5:07 PM
To: [email protected]; [email protected]
Subject: Re: [VoiceOps] Local ringback on SIP 180 from Broadsoft media
server vs phone generated RBT
In general, I advise my clients to not generate ringback tone on phones.
Best practice is to have phones indicate alerting state by responding with
180 RINGING with no SDP, and require PRACK method. Media flow from phones
before 200 OK may cause other problems, especially in a simultaneous ringing
environment.
One common practice is that 180 RINGING is sent without SDP, and a media
gateway closer to the caller furnishes the ringback tone. PRACK is
optionally used to ensure that the provisional response is reliable.
Another common practice is to send 183 PROGRESS with SDP indicating the
availability of early media and progress tone, but that practice isn't
bullet proof.
Hope this helps. If you would like additional discussion, please feel free
to contact me off list.
John S. Robinson
[email protected]
Communichanic Consultants, Inc.
On 11/5/2012 23:40, John Botha wrote:
We are debating on having our Broadsoft media server generating RBT on a SIP
180 vs having the phone generate it locally, which is currently the case.
We have found sporadic ringback issues when the phones generate local RBT
when it plays one ring and then goes silent or no RBT at all. This only
happens once out of approximately 10 calls though, and signalling looks
normal (ie no 180 followed by 183 or duplicate messaging).
The end-user hardware devices are mostly Polycom.
Does anyone have some experience, advice and information this?
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121107/4fbdbeff/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 7 Nov 2012 10:16:11 -0500
From: PE <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] Strange calling patterns
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Ryan, did this clear up?
On Nov 5, 2012, at 7:09 PM, Ryan Delgrosso <[email protected]> wrote:
> All,
> So I know with the election tomorrow all bets are basically off for weird
> calling patterns but I have seen some really strange stuff today and was
> hoping someone else might have seen it as well or be able to validate some
> theories.
>
> I had a number in a Michigan exchange receive 99,000 inbound calls in a
> single hour (no that is actually ninety nine thousand) and that user had
> their number forwarded off to another overloaded Michigan exchange so it
> generated nearly a million outbound call attempts as my system attempted to
> find an open trunk to get through. Earlier I had a similar case with a
> Florida exchange where a single user received 150,000 calls in an hour all
> with invalid source numbers, and all arrived through otherwise reputable
> origination carriers (L3, Paetec etc).
>
> The commonality here is that in both cases the customer account had no
> registered device and had forwarding setup, and the destination for both was
> an overloaded exchange in a swing state. In all cases I have suspended the
> accounts and stopped the traffic but it still doesn't give me the warm and
> fuzzies.
>
> My first inclination is this feels like some kind of DDOS to hurt polling or
> last minute campaigning since if the attempts were legitimate they wouldn't
> be winning supporters by calling them 150,000 times but im really open to
> ideas here.
>
>
> Anyone out there with some experience or theories, feel free to chime in or
> reply off list if paranoid.
>
> -Ryan
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
End of VoiceOps Digest, Vol 41, Issue 7
***************************************
