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/It...
-- 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.
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/It...
-- 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 VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
An aggregator documents this as: In order for the carriers to re invite T.38, your initial invite must have G.729a (1) as priority. If you want your switch to re invite T.38 your initial invite must have G.711u (2) as priority. INVITE Codec priority in SDP 1. m=audio xxxxxx RTP/AVP 18 0 101 2. m=audio xxxxxx RTP/AVP 0 18 101 T.38 interop in my experience sucks. Faxing completion with 711 generally works, and is the most stable, especially as your carrier count (and interop complexity) increases... On Thu, Sep 19, 2013 at 2:47 PM, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
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/It...
-- 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 VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (3)
-
jackson.tim＠gmail.com -
lindsey＠e-c-group.com -
ryandelgrosso＠gmail.com