Solved: Figuring Out SIP Session Information from SDP Messages?

Matthew Martin · ‎07-21-2015

Hello All,

I am trying to figure out how I can tell whether or not people sending us Faxes are capable of negotiating T.38 Fax Protocol or not.

I have now read over and over that this information is advertised in the SDP data, but NO site that I found said what exactly you're supposed to look for to figure that out. I have seen a bunch of illusrtations showing something similar to a Call Flow Diagram and in the INVITE/ACK of the flow it says "..T.38 is advertised here..", but what am I supposed to look for..?

Given the SIP INVITE below, which I believe is the very first SIP message recevied for this particular call, can you tell from this whether or not T.38 is being advertised as being capable from the Originating Gateway (*OGW is the customer dailing into us for this call)?

INVITE sip:1112223333@192.168.11.9:5060 SIP/2.0
Via: SIP/2.0/UDP 10.60.124.200:5060;branch=z9hG4bK1F3DDCDA1
From: "***NAME REMOVED***" <sip:4445556666@10.101.0.5>;tag=66AB8EE8-1BFA
To: <sip:1112223333@192.168.11.9>
Date: Tue, 21 Jul 2015 19:47:50 GMT
Call-ID: 343D310E-2F1811E5-B9D8A9F2-5CA70811@10.60.124.200
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0876305558-0790106597-3117591026-1554450449
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1437508070
Contact: <sip:4445556666@10.60.124.200:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 309

v=0
o=CiscoSystemsSIP-GW-UserAgent 7195 9014 IN IP4 10.60.124.200
s=SIP Call
c=IN IP4 10.60.124.200
t=0 0
m=audio 29510 RTP/AVP 18 0 101 19
c=IN IP4 10.60.124.200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000

So is it possible given the SIP message above to figure out whether or not the customer is advertising T.38 to us? Or if you find that in a different SIP Message other then the INVITE, just let me know and I'll try to find it...

Any thoughts or suggestions would be greatly appreciated!

Thanks in Advance,
Matt

Nadeem Ahmed · ‎07-21-2015

Hello Matt,

The main difference between normal voip call is the type of media established between two endpoints is different , Traditionally in Fax over IP call T.38 stream . T.38 session should be described in SDP using the image/T.38

you would see addition attribute in the SDP parameter.

m=image 4908 udptl t38
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv

This first line is an instruction to the callee to send media of type “image” to port “4908” where “t38” is most preferred. The following lines (a=) are media attributes. The following lines in the INVITE describe the media type and the direction of streams (bi-directional). i.e. the connection will be set in send and receive mode.

which seems INVITE is not containing any T.38 fax negotiation here. but yes complete message would be quite more helpful.

Br,

Nadeem

Br, Nadeem Please rate all useful post.

View solution in original post

Terry Cheema · ‎07-21-2015

Hi Matt,

Your SIP debug message is not complete. It is just the initial Invite message. All the Fax calls are initiated as audio calls. Once the terminating gateway hears the fax tones, it then determines it has to switch the codec to a fax codec. It then sends re-invites containing fax codec information.

If you post the full debug message only then we can determine, what codec is negotiated.

-Terry

Please rate all helpful posts.

Terry Cheema · ‎07-21-2015

Refer here as well, but as mentioned earlier, Fax calls are setup as audio calls and codec switchover happens later once fax tones are detected and then only Fax protocol related info can be seen in the SDP.

http://www.cisco.com/c/en/us/support/docs/voice/t38/116280-configure-cube-00.html

SIP

Enable these debugs for SIP:

debug voip ccapi inout
debug ccsip mess

After the voice call is set up, the TGW sends a SIP ReINVITE to the OGW through CUBE. If the switchover is successful, the OGW responds with a SIP 200 OK with the correct Session Description Protocol (SDP) parameters.

T.38 Switchover

INVITE sip:2101@10.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK171D71
Remote-Party-ID: <sip:1101@10.0.0.2>;party=calling;screen=no;privacy=off
From: <sip:8141101@10.0.0.2>;tag=8D815D8-646
To: <sip:2101@10.0.0.1>;tag=DD4D344-21B2
Date: Fri, 25 Feb 2011 19:25:15 GMT
Call-ID: 32395B08-403E11E0-818C9D5B-499FBE40@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 786980147-1077809632-2173148507-1235205696
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, 
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1298661915
Contact: <sip:8141101@10.0.0.2:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 384

v=0
o=CiscoSystemsSIP-GW-UserAgent 3745 9509 IN IP4 10.0.0.2
s=SIP Call
c=IN IP4 10.0.0.2
t=0 0
m=image 17682 udptl t38
c=IN IP4 10.0.0.2
a=T38FaxVersion:0
a=T38MaxBitRate:7200
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:180
a=T38FaxUdpEC:t38UDPRedundancy

!!NOTE!! Not all of the above bolded fields are required. 
The above is an example of how Cisco implements T38.

-Terry

Mohammed al Baqari · ‎07-21-2015

Hi,

The explanation mentioned by Terry is how SIP T38 fax works. I am putting it here in steps with small diagram.

Initially SIP call is established using SIP invite messages.
Once the call established, the TGW detects a fax V.21 flag sequence from the called fax machine and sends an INVITE with T.38 details in the SDP field to the OGW or to the SIP proxy server, depending on the network topology. The SDP details are listed in above post by Terry.
The OGW receives the INVITE message and sends back a 200 OK message.
The TGW acknowledges the 200 OK message and sends an ACK message direct to the OGW
The OGW starts sending T.38 UDP packets instead of VoIP UDP packets across the same ports (RTP stream with different payload type)
At the end of the fax transmission, another INVITE message can be sent from TGW to return to VoIP mode

Matthew Martin · ‎07-22-2015

Hey All, thanks for the replies, much appreciated!

Some great info here guys, thanks for the explanations.

So, if I'm understanding correctly. The Call begins out looking like a normal VoIP "audio" call/session. Then, once the OGW picks-up/hears the fax tone being emitted from the TGW it sends another INVITE to the TGW with new SDP information, this time containing the T38 data. Then, once the fax/call has completed the TGW sends another INVITE message returing the call to VoIP before ending the current call/session... Does that sound about right?

Terry, yes those are the debugs I have enabled on our SIP CUBE. All the debugs from our CUBE(s) get sent to a remote syslog server so we can store a day or 2 of messages in case we need to go back and check them out, or if TAC needs them for any reason.

Rtr-2911-RGN01#show debugg
CCAPI:
debug voip ccapi inout is ON (filter is OFF)
CCSIP SPI:
SIP Call Message tracing is enabled (filter is OFF)

Also, during the entire transaction, is there any kind of "ID" of the SIP Messages that remains the same throughout the whole process..? I thought maybe the "Call-ID" did, however it looks like that does change. I noticed it changed when, for example, the Call-ID was one value when communicating with the SIP Trunk and then it was different when it went began talking to CallManager... So is there any unique value that stays with the Session throughout the entire call?

Again, thank you all for the excellent explanations.

Thanks Again,
Matt

Mohammed al Baqari · ‎07-22-2015

Hi,

The call ID will vary between the VoIP call and T38 call as they are two seperate processes from signaling perspective. Both calls can be linked using calling/called number

Matthew Martin · ‎07-22-2015

Hey Mohammed, thanks for the reply...

Ok, so I guess there is no Unique Key or ID to link them, just the called and calling numbers... Which I guess techincally isn't actually unique, since 2 different calls could be happening simultaneously, where for example, Mike from Company A could have called Joe in Company B, and at the same time Jane from Company A called Sue from Company B. In this case you'd get the same called and calling numbers...

Thanks Again,
Matt

Matthew Martin · ‎07-22-2015

Ok, so I have one other question.

I found a bunch of good examples on our SIP CUBE's syslog server and in Callmanager's RTMT > Session Trace, I was going to attach it but I can't attach text files apparently. *See attached image...

But anyway, the one I was going to attach was from CallManager RTMT > Session Trace > Trace Call, which was for a call to one of our Fax Machines. In that example I found that on the 3rd INVITE, that's where you can see the T38 stuff coming into play. Which seems to be working well when both parties are T.38 capable.

However, in the case that the person faxing us, or the person we are faxing to, is NOT configured to use T.38 what "should" happen in this case. Is this where you would want to use "pass-through"?
I believe this is what we were using before we configured T.38... So when this happens how do you tell the fax call to use "pass-through", does this happen automatically when T.38 is NOT available with both OGW and TGW..?

For example, on our SIP CUBE we have this configured:

!
voice service voip
  ......
  fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
  ......
!
...
------cut------
...
!
dial-peer voice 20 voip
  description ==> Incoming SIP dial-peer
  translation-profile incoming IPATH-IN
  session protocol sipv2
  incoming called-number .
  voice-class codec 1
  voice-class sip profiles 1
  voice-class sip bind control source-interface Loopback0
  voice-class sip bind media source-interface Loopback0
  dtmf-relay rtp-nte
  no fax-relay sg3-to-g3
  no vad
!

And on one of our H.323 Gateways (*Cisco 2821), which only has Fax Machines connected to it, has the following:

!
voice service voip
  fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
!
...
--------cut-------
...
!
dial-peer voice 10009 voip
  translation-profile outgoing VOIP-OUT
  destination-pattern 91[2-9]..[2-9]......
  session target ipv4:10.60.11.9
  dtmf-relay h245-alphanumeric
  codec g711ulaw
  no fax-relay sg3-to-g3
  clid network-number 6106480500
  no vad
!
dial-peer voice 99999 voip
description incoming call leg - catch all
incoming called-number .T
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!

I believe before we configured our 2821s and our 2911 SIP CUBEs to use T.38, we had the config command:

"fax protocol pass-through g711ulaw"

in some or most of the dial-peers. Then we removed the "pass-through" line above and then had to add the line

"fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none"

to the "voice service voip" section of the config.

But now, it seems like incoming faxes not using the T.38 protocol are failing... Is there a way to configure a "backup" method of sending and receiving faxes when T.38 is not available by both parties?

Thanks Again,
Matt

Nadeem Ahmed · ‎07-21-2015