[VoiceOps] T.38 re-invites

[PE]

I am not aware of any restrictions, per se. At the SIP layer, either side
can re-INVITE. That said, I think it would be unusual for the sender try to
renegotiate. Convention says that the receiver will renegotiate because
they answer the call and are presented a fax tone which prompts the change
to T38.



On Wed, Jan 4, 2012 at 4:35 AM, Nathan Anderson <nathana at fsr.com> 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.
>
> --
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120104/b27ab9f4/attachment.html>