[OpenSIPS-Users] b2b top-hiding ate a 491

[Ovidiu Sas]

On Thu, Mar 17, 2011 at 8:38 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
> Ovidiu,
>
> Acknowledged on the b2b module.
>
> In my experience it depends on the carrier.  Some cases either side
> can/will send the re-invite.  In other cases, the term carrier requires
> that the originating side send the re-invite (the Adtran in this case).
>
> The Adtran CPE can be configured to do any of the above.  It can be
> configured to send a G711 or T.38 re-invite on the detection of any
> variety of signals:  v8-ansam, v25, v21 preamble, etc.  It's quite
> flexible.  We've found the T.38 success rate increases with the sooner the
> re-invite is generated, so we send it as soon as possible.  I believe that
> is the v8-ansam or v8-ansam-pr tone.  This does break modem compatibility.
>  One thing it cannot differentiate (to the best of my knowledge) is
> whether it is the term or orig side when it comes to the re-invite
> behavior.  The global "voice fax-tone ..." command set applies to all
> calls on all ports if the DSP detection is enabled on a particular port.
>
> Do you have any links to RFCs or other documents that say the term side
> should be the one to generate the re-invite?  I'm not against it, but I
> would like to review it and send it to some of my upstream carrier
> partners since it is contrary to their configuration.

IIRC, the T.38 spec requires this.  The V.21 preamble is the sequence
that should trigger the T.38 re-negotiation because it is a clear
indication that this is a fax and not a modem call.  You don't want to
switch to T.38 for modem calls.
V.21 preamble should be detected on the termination side (receiver of
fax) because the sequence is generated there.


Hope this helps.
Ovidiu


> On 3/17/11 4:25 PM, "Ovidiu Sas" <osas at voipembedded.com> wrote:
>
>>This seems to be an issue with the b2b module, but there's also an
>>issue with the Adtran CPE.
>>If the fax is sent from the Adtran CPE to PSTN, then the PSTN GW is
>>the one that detects the preamble and therefore responsible for
>>re-negotiation.  The Adtran CPE should not send a re-INVITE, instead
>>it should wait for the re-INVITE initiated by the PSTN GW.
>>
>>
>>Regards,
>>Ovidiu Sas
>>
>>On Thu, Mar 17, 2011 at 4:11 PM, Jeff Pyle <jpyle at fidelityvoice.com>
>>wrote:
>>> Hello,
>>>
>>> The scenario is this:
>>>
>>>       Adtran CPE
>>>            |
>>>            |
>>>     Opensips proxy 1
>>>            |
>>>            |
>>>     Opensips B2BUA
>>>            |
>>>            |
>>>     Opensips proxy 2
>>>            |
>>>            |
>>>       PSTN Gateway
>>>
>>>
>>> Opensips is 1.6.4 installed from Debian packages in all cases.
>>>
>>> The Adtran CPE placed a fax G729 call through the Opensips network and
>>>out
>>> through the PSTN carrier.  After 200 OK, the PSTN carrier sent a
>>>re-INVITE
>>> for G711.  At nearly the same time the Adtran CPE sent a re-INVITE for
>>> T.38.
>>>
>>> The SIP traces at Opensips proxies 1 and 2 show each side sent a 491
>>> Request Pending to the other.  The traces also show the Opensips B2BUA
>>> running in top-hiding mode didn't pass the CPE->PSTN 491.  Consequently
>>> the PSTN gw continued to reply with 491s to the CPE's repeated attempts
>>>to
>>> go to T.38 since as far as it knew it still had an outstanding re-INVITE
>>> of its own.
>>>
>>> An examination of the Opensips B2BUA log has the following:
>>>
>>> ERROR:b2b_entities:b2b_tm_cback: No dialog found reply 200 for method
>>>BYE,
>>> [2566600-0-561c-4e442-737b62ad-4e442 at ww.xx.yy.zz]
>>>
>>> This is probably because the call didn't tear down in the cleanest
>>> possible way.  The two different proxies show slightly different
>>>versions
>>> of the same thing, including 491s, and 501s for out-of-transaction BYEs.
>>>
>>> Of course this is the perfect storm.  Being able to duplicate the timing
>>> that caused the 491s in the first place is going to be next to
>>>impossible.
>>>  My sipp knowledge is not up to the task I'm afraid.  My hope is perhaps
>>> this is/was a known problem and it has already been corrected.  If not,
>>> any thoughts on what might have caused the B2BUA to eat a 491?
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>