[VoiceOps] T.38 re-invites

[Michael Miller]

That is mine experience also.  However; some Cisco router configs may cause
the receiver not too re-negotiate.

On Wed, Jan 4, 2012 at 8:24 AM, PE <peeip989 at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/f371cd6b/attachment.html>