Summary:ASTERISK-18401: Debugging messages generated by 'udptl debug' are incomplete
Reporter:Kevin P. Fleming (kpfleming)Labels:
Date Opened:2011-08-31 17:18:02Date Closed:2011-10-06 12:51:25
Versions: Frequency of
is related toASTERISK-18394 T.38 FAX passthrough does not work
Environment:Attachments:( 0) jira_asterisk_18401_v1.8.patch
Description:In a two-channel bridge where T.38 is in use, if 'udptl debug' is enabled, debugging messages are generated for each UDPTL packet sent or received. These messages include the channel name the packet was sent or received on... except some messages only include the channel technology, not the channel name. See the log on the related issue for an example.
Comments:By: Matthew Nicholson (mnicholson) 2011-09-01 09:59:16.236-0500

In the debug messages for the received packets, the seqno is always 0 as well.

By: Matthew Nicholson (mnicholson) 2011-09-01 10:03:19.718-0500

The offending code seems to be in the {{change_t38_state()}} function in {{chan_sip.c}}.

ast_udptl_set_tag(p->udptl, "SIP/%s", p->username);

If username is blank, the debug messages just contain 'SIP/'.

By: Kevin P. Fleming (kpfleming) 2011-09-01 11:10:45.647-0500

In the logs attached to ASTERISK-18394, the sequence numbers are all zero because the endpoint that sent the packets does not increment the sequence numbers as it should. I don't think this the fault of the 'udptl debug' code.

By: Richard Mudgett (rmudgett) 2011-10-05 15:56:58.808-0500

[^jira_asterisk_18401_v1.8.patch] does the following:

* Makes chan_sip set the tag to the channel name.

* Fixes received debug message sequence number.

* Removed tx/rx debug message type since it was hard coded to 0.

* Made udptl.c logged message header consistent if possible: "UDPTL (%s): ".

* Removed unused rx_expected_seq_no from struct ast_udptl.

By: Richard Mudgett (rmudgett) 2011-10-05 15:58:22.425-0500

Could you give this patch a sanity check?

By: Matthew Nicholson (mnicholson) 2011-10-06 11:49:53.571-0500

Looks good to me.