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

[Ovidiu Sas]

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
>