[asterisk-dev] T38 woes, possible answer

[Dan Austin]

The logs attached to 7844 an 7679 provided enough detail after
a deeper took in chan_sip.

I found that in each case a call started on RTP and switched 
to T38.  At the point that T38 negotiation completes, the code
changes the port.  The T38 and RTP stacks use the same variable
to store the port information.  When the port changes, the RTP
Stack 'notices' the change and triggers the callback
sip_set_rtp_peer, which in case of a port change calls
transmit_reinvite_with_sdp() and boom no more T38.

I attached a patch to 7844, which is nothing more than:
if (p->t38.state == T38_ENABLED){
	ast_mutex_unlock(&p->lock);
	return 0;
}

Right above the if (rtp){} test.  I don't have any T38 gear,
so I cannot test this, but the logic seems to hold.  I don't
know that this will be enough to close both bugs, but I think
it will allow them to move on to the next issue :-)

Oh, and bug 8078 which appears to be related is actually due
to the endpoint using "UDPTL" instead of "udptl" in the media
offer.  I looked over the RFCs and the endpoints seem to be
within spec to use all upper case in the m: element.  Any 
thoughts on this issue?

Dan



-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Johansson
Olle E
Sent: Thursday, November 09, 2006 10:53 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] T38 woes, possible answer


9 nov 2006 kl. 23.31 skrev Dan Austin:

> Perhaps I have too much time on my hands, but I have been
> monitoring the T38 bugs, reviewing the logs and the code
> in chan_sip to see if I could help move those bugs along.
> I don't have any T38 capable endpoints, so I didn't expect
> to make much progress.
>
> However, I think I see an issue that might explain the
> current failure mode.
>
> In bug-id 7844 the logs show what appears to be a successful
> T38 negotiation followed by an immediate RTP re-invite.
>
> The issue appears to be in one or both of these functions:
>
> handle_request() case SIP_ACK: calls check_pending() which has
> no idea of t38.state
>
> -- or --
> handle_request_invite() case 200: calls check_pending() which has
> no idea of t38.state
>
> check_pending() likely does not need to know about t38.state,
> but perhaps sip_handle_t38_reinvite() should clear the
> SIP_NEEDREINVITE flag so that check_pending will not start the
> whole process over.
>
> Thoughts?

The whole idea that the T38 is related to the canreinvite setting
is propably something we need to take away. The NEEDREINVITE
and CANREINVITE setting is more aimed toward RTP redirect to other
IPs than related to re-inviting to another media stream, same IP.

Accidentally, I changed parts of this yesterday in Pineapple and have on
my todo-list to check for chan_sip, but did not note what you write  
above.
Please continue this investigation!

/O
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev