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. Verizon T.38 (Ball, Jared)
2. test (Jared Ball)
3. Re: test (Todd Wolf)
4. Re: test (Nick D'Attilo)
5. Verizon T.38 (Jared Ball)
6. Re: Major carriers and odd T.38 behavior (Ryan Delgrosso)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 Sep 2013 19:53:34 +0000
From: "Ball, Jared" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [VoiceOps] Verizon T.38
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Does anyone have an experience with T.38 Interoperability with Verizon? I have
eight different telephone numbers in different area codes \ prefixes. Some
re-invite T.38 and other re-invite G.711 only. I've done multiple tests on
these numbers with consistent results.
Bad numbers:
412-469-02XX
412-469-40XX
615-850-XXXX
858-693-XXXX
Good numbers:
503-205-02XX
858-695-XXXX
502-205-01XX
I have a trouble ticket open with Verizon. I can tell from the SIP signaling
that they are using Sonus but it isn't clear whether their configuration and
support for T.38 is uniform across their platform.
Is Verizon's support for T.38 usually consistent? I have a Ditech PVP that I
can use for transcoding. Should I just assume that I'll need to transcode some
of the time? My Fax Server is T.38 only and will rejects calls with "488 Not
acceptable here". My Ditech PVP is end of life so if transcoding is a
requirement I may be looking for a new transcoding solution.
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20130919/fc137965/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 19 Sep 2013 12:50:55 -0700
From: Jared Ball <[email protected]>
To: [email protected]
Subject: [VoiceOps] test
Message-ID:
<CAAxSk1FMJyddgivCspUJQ=ocp7aswz9rxd+bznlef1wh5kr...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
test
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20130919/a6eb0fcd/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 19 Sep 2013 20:17:27 +0000
From: Todd Wolf <[email protected]>
To: Jared Ball <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [VoiceOps] test
Message-ID: <DCD0554F601CF946A51CAE28BBABDC4CF9C5B08EB5@mb001>
Content-Type: text/plain; charset="us-ascii"
Got it
From: VoiceOps [mailto:[email protected]] On Behalf Of Jared Ball
Sent: Thursday, September 19, 2013 3:51 PM
To: [email protected]
Subject: [VoiceOps] test
test
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20130919/8a83e70e/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 19 Sep 2013 16:54:25 -0400
From: "Nick D'Attilo" <[email protected]>
To: Todd Wolf <[email protected]>
Cc: "[email protected]" <[email protected]>, Jared Ball
<[email protected]>
Subject: Re: [VoiceOps] test
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Test
Nicholas J. D'Attilo
Manager - Network Operations Center
Rockefeller Group Technology Solutions, Inc.
1221 Avenue of<x-apple-data-detectors://0> the Americas Concourse Level
New York, NY 10020<x-apple-data-detectors://1/0>
Phone:1.212.282.2304<tel:1.212.282.2304>
[http://www.rgts.com/images/linkedIn-icon.png]<http://www.linkedin.com/in/nickdattilo>
On Sep 19, 2013, at 16:18, "Todd Wolf"
<[email protected]<mailto:[email protected]>> wrote:
Got it
From: VoiceOps [mailto:[email protected]] On Behalf Of Jared Ball
Sent: Thursday, September 19, 2013 3:51 PM
To: [email protected]<mailto:[email protected]>
Subject: [VoiceOps] test
test
_______________________________________________
VoiceOps mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
Message: 5
Date: Thu, 19 Sep 2013 11:40:18 -0700
From: Jared Ball <[email protected]>
To: [email protected]
Subject: [VoiceOps] Verizon T.38
Message-ID:
<caaxsk1gwzy8am_ljqtssug8qwrml8jag9ltx0ge3go6qwcz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Does anyone have an experience with T.38 Interoperability with Verizon? I
have eight different telephone numbers in different area codes \ prefixes.
Some re-invite T.38 and other re-invite G.711 only. I've done multiple
tests with consistent results.
Bad numbers:
412-469-02XX
412-469-40XX
615-850-XXXX
858-693-XXXX
Good numbers:
503-205-02XX
858-695-XXXX
502-205-01XX
I have a trouble ticket open with Verizon. I can tell from the SIP
signalling that they are using Sonus but it isn't clear whether their
configuration and support for T.38 is uniform across their platform.
Is Verizon's support for T.38 usually consistent? I have a Ditech PVP that
I can use for transcoding. Should I just assume that I'll need to
transcode some of the time? My Fax Server is T.38 only and will rejects
calls with "488 Not acceptable here". My Ditech PVP is end of life so if
transcoding is a requirement I may be looking for a new transcoding
solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20130919/3c9b24c0/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 19 Sep 2013 14:47:08 -0700
From: Ryan Delgrosso <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] Major carriers and odd T.38 behavior
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mark,
While I have a number of carriers I work with that all use Sonus gear,
ive never actually hit this limitation with fax re-invite. I wonder if
some other nuance is triggering this behavior rather than simply "the
call began as G711"
Can you perhaps share a capture of the issue?
On 09/19/2013 11:07 AM, Mark R Lindsey wrote:
> I've recently bumped into some odd restrictions with the largish (nationwide,
> incumbent LEC) Sonus-based SIP carriers, such as:
>
> (a) Carrier Restriction: If g711u is the preferred codec in a call, then the
> call will never be re-invited to T.38.
>
> Implication: Any call from a line that could be connected to a fax machine
> cannot be started with G.711 as the preferred codec.
>
> (b) Carrier Restriction: The SIP carrier will never send the T.38 re-INVITE,
> even if the call is going to the SIP Carrier.
>
> Implication: I have to use SIP-POTS gateways (ATAs, IADs) that are able to
> re-INVITE to T.38 when they originate the call, while many ATAs/IADs would
> expect the receiving T.38 device to do the re-INVITE.
>
> It seems like these implications limit the options available for ATAs and
> IADs, and the intended use of codecs for commercial lines that may carry both
> voice and fax.
>
> Has anyone successfully worked through it all?
>
> On Jan 10, 2012, at 1:15, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
>
>> I have seen numerous scenarios where a softswitch acting as a forking proxy
>> will use a dummy SDP in its outgoing invite (Metaswitch and Sylantro both
>> come to mind here), and immediately will re-invite when the far end has
>> answered.
>>
>> I have also seen numerous scenarios where fax servers will send the initial
>> invite with G711 and then instantly re-invite to T.38 upon answer.
>>
>> Dont stand on convention or BCP here, the re-invite often comes from the
>> calling party, and sometimes a few times.
>>
>> On 01/04/2012 06:46 AM, Mark R Lindsey wrote:
>>> The IETF informational draft: "SIP Support for Real-time Fax: Call Flow
>>> Examples And Best Current Practices" shows the re-INVITEs from the called
>>> party. This is still conventional best practice.
>>>
>>> http://tools.ietf.org/html/draft-ietf-sipping-realtimefax-01
>>>
>>>
>>> Mike Coffee's talk at SIPNOC 2011 discussed the expectations, showed how
>>> things can fall apart:
>>>
>>>
>>> http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,115/Itemid,261/
>>>
>>>
>>> -- Mark R Lindsey mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
>>>
>>>
>>>
>>>
>>> On Jan 4, 2012, at 04:35 , Nathan Anderson wrote:
>>>
>>>> This might not be the most appropriate forum for such a question, but
>>>> given that implementation bugs in either NOC gear or CPE gear can cause
>>>> headaches for network operators, I offer this here in the hope that
>>>> perhaps a fellow VoiceOp here may have run into this before and knows the
>>>> answer...
>>>>
>>>> It is my understanding that with SIP, *either* party to a call can send
>>>> another INVITE (a so-called "re-invite") at any time during an active
>>>> session; this could be used to change the endpoint of a call or redirect
>>>> it elsewhere, and is also commonly used to renegotiate the media in use
>>>> (audio, video, image, and associated codecs) without dropping the call
>>>> even while the endpoints remain the same.
>>>>
>>>> Does this hold true, though, for re-invites whose purpose is to switch
>>>> from an RTP audio stream to a T.38 UDPTL stream? Can *either* peer send
>>>> that INVITE? Or is there a rule -- spoken or unspoken -- that states that
>>>> a T.38 re-invite can only be initiated by the *receiver* of the fax, and
>>>> not the transmitter?
>>>>
>>>> I have some ATAs that appear to send out a T.38 re-invite upon detection
>>>> of a fax tone regardless of whether the ATA placed the call or answered
>>>> the call, and if I am understanding what I'm seeing in my packet captures,
>>>> I think the fact that these ATAs do this even when they are going to play
>>>> the role of the T.38 transmitter is confusing the heck out of my
>>>> (Asterisk) SBC and the termination provider. But I can't find any
>>>> concrete evidence to support the idea that T.38 re-invites should only be
>>>> initiated by the receiver.
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
Subject: Digest Footer
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
End of VoiceOps Digest, Vol 51, Issue 2
***************************************
