This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I'm capturing fax calls from our fax server going out over a SIP connection. The 'From' field shows up as I would like it to 'SIP:[email protected]', I configured this on my RightFax board server, but the 'To' field just shows up as 'SIP:9'. I need to see the fax number being dialed. Am I capturing the wrong adapter? Or is there a setting where I can configure what the column displays? I see the fax number at the t.38 level when I graph it out, but I need to see it in the list of calls prior to the graph so I can select the right one to graph.

asked 19 May '14, 15:43

JackieB727's gravatar image

JackieB727
11113
accept rate: 0%


"sip:9" indicates that the digit "9" is the only digit collected for the INVITE request. Its possible that the rest of the digits may be being sent via DTMF relay or inband DTMF if using g.711 codec. A sample trace of a completed fax setup would really help to drill down further.

permanent link

answered 19 May '14, 19:25

Rooster_50's gravatar image

Rooster_50
23891218
accept rate: 15%

Hi, thanks for the reply. Here's a sample of the call setup. Would I need to modify Wireshark to capture the number differently? xxx-xxx-5076 is the number I'm trying to capture in the 'To' field.

     |                   
|563.948  |         INVITE SDP ( g711U g711A)          |SIP From: sip:[email protected] To:sip:
|         |(5060)   ------------------>  (5060)   |
|563.971  |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|564.303  |         180 Ringing                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|567.727  |         200 OK SDP ( g711U g711A)          |SIP Status
|         |(5060)   <------------------  (5060)   |
|567.728  |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|567.742  |         RTP (g711A)                   |RTP Num packets:322  Duration:6.421s SSRC:0x18BE
|         |(56016)  ------------------>  (6350)   |
|567.757  |         RTP (g711A)                   |RTP Num packets:133  Duration:2.640s SSRC:0xD2822D50
|         |(56016)  <------------------  (6350)   |
|570.437  |         RTP (RTPType-103)             |RTP Num packets:183  Duration:3.640s SSRC:0xD2822D50
|         |(56016)  <------------------  (6350)   |
|574.119  |         INVITE SDP ( t38)             |SIP Request
|         |(5060)   <------------------  (5060)   |
|574.120  |         200 OK SDP ( t38)             |SIP Status
|         |(5060)   ------------------>  (5060)   |
|574.154  |         ACK       |                   |SIP Request
|         |(5060)   <------------------  (5060)   |
|574.166  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|574.414  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|576.897  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  <------------------  (6352)   |
|579.997  |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(56016)  <------------------  (6352)   |
|581.557  |         NSF       |                   |t38:v21:HDLC:Non-Standard Facilities
|         |(56016)  <------------------  (6352)   |
|582.257  |         CSI Num: xxx-xxx-5076           |t38:v21:HDLC:Called Subscriber Identification
|         |(56016)  <------------------  (6352)   |
|582.697  |         DIS DSR:ITU-T V.27 ter, V.29, and V.17          |t38:v21:HDLC:Digital Identification Signal
|         |(56016)  <------------------  (6352)   |
|582.758  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|582.777  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  <------------------  (6352)   |
|582.836  |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(56016)  ------------------>  (6352)   |
|583.836  |         TSI Num: companyname.ORG RFTestServer          |t38:v21:HDLC:Transmitting Subscriber Identification
|         |(56016)  ------------------>  (6352)   |
|584.446  |         DCS DSR:14 400 bit/s, ITU-T V.17          |t38:v21:HDLC:Digital Command Signal
|         |(56016)  ------------------>  (6352)   |
|584.633  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|584.711  |         v17-14400-long-training          |t38:t30 Ind:v17-14400-long-training
|         |(56016)  ------------------>  (6352)   |
|586.102  |         t4-non-ecm-data:v17-14400          |t38:t4-non-ecm-data:v17-14400 Duration: 1.47s No packet lost
|         |(56016)  ------------------>  (6352)   |
|587.633  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|587.711  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|588.778  |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(56016)  <------------------  (6352)   |
|589.837  |         CFR       |                   |t38:v21:HDLC:Confirmation To Receive
|         |(56016)  <------------------  (6352)   |
|589.899  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  ------------------>  (6352)   |
|589.918  |         no-signal |                   |t38:t30 Ind:no-signal
|         |(56016)  <------------------  (6352)   |
|589.977  |         v17-14400-short-training          |t38:t30 Ind:v17-14400-short-training
|         |(56016)  ------------------>  (6352)   |
|590.368  |         FCD Frm num: 0                |t38:v17-14400:HDLC:Facsimile coded data
|         |(56016)  ------------------>  (6352)   |
(20 May '14, 13:27) JackieB727

@JackieB727

Its difficult to tell exactly without seeing the actual trace, but from the summary you provided below, there are 183 dynamic RTP packets in the trace. Usually dynamic RTP indicats some type of telephony event such as DTMF. I think it is fair to say that digits are being sent in-band via dynamic RTP telephony events once the session has been established. Your devices look to be set to use/recognize RTP Payload Type 103 as DTMF. The snippet below shows the line in your sample to indicate the events I am talking about.

"570.437 RTP (RTPType-103) RTP Num packets:183 Duration:3.640s"

I have seen instances where the digits are visible in the payload. You could filter on the payload type with "rtp.p_type==103" and then create a column "rtp.payload". In the payload, look for the first instance of the byte "18". In my experience, the byte following the "18" is your DTMF digit. There will be multiple instances of this pattern in the payload depending on the length of sample size, and multiple packets of the same digit depending on the length of the DTMF tone duration.

Its very easy to see DTMF events if the UA's are using RFC2833 DTMF relay.

If you want further, more accurate analysis, you really should provide an actual trace. I really hope this helps.

(20 May '14, 18:00) Rooster_50
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×139
×34
×30

question asked: 19 May '14, 15:43

question was seen: 4,891 times

last updated: 21 May '14, 03:34

p​o​w​e​r​e​d by O​S​Q​A