[Home]

Summary:ASTERISK-10145: Some information from INVITE of Peer A not passed to INVITE of Peer B
Reporter:Christoph Stadlmann (cstadlmann)Labels:
Date Opened:2007-08-23 01:32:24Date Closed:2011-06-07 14:02:57
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) fulldebug.txt
( 1) SIP_log.txt
Description:If Asterisk get's multiple 'm=' information in initial invite of peer A, it does not send this information to Peer B:

This is INVITE of Peer A (Caller):

INVITE sip:073261066060@voip.mywave.at SIP/2.0
Via: SIP/2.0/UDP 83.65.56.172:5060;branch=z9hG4bKdc93a9e82
Max-Forwards: 70
Content-Length: 287
To: sip:073261066060@voip.mywave.at
From: sip:440715@83.65.56.172:5060;tag=f69b00ed276775f
Call-ID: 7174400498466f716e592f9eadf1efdd@83.65.56.172
CSeq: 1572731910 INVITE
Route: <sip:voip.mywave.at;lr>
Supported: timer
Contact: sip:440715@83.65.56.172:5060
Content-Type: application/sdp
Proxy-Authorization: Digest response="38c56b890e7564d517621f7867ad6a90",username="v205722ad",realm="asterisk",nonce="2beb9d8e",algorithm=MD5,uri="sip:073261066060@voip.mywave.at"
Supported: replaces
User-Agent: Patton S-DTA EUI MxSF v3.2.8.45 00A0BA02AFB5 R3.21 2007-05-14 SIP

v=0
o=MxSIP 0 16 IN IP4 83.65.56.172
s=SIP Call
c=IN IP4 83.65.56.172
t=0 0
m=audio 4912 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=image 4914 udptl t38
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv


This is INVITE to Peer B (Callee):

INVITE sip:073261066060@212.31.71.22 SIP/2.0
Via: SIP/2.0/UDP 85.193.128.15:5060;branch=z9hG4bK2225ce61
From: "+43720440715" <sip:+43720440715@85.193.128.15>;tag=as73fa5fb6
To: <sip:073261066060@212.31.71.22>
Contact: <sip:+43720440715@85.193.128.15>
Call-ID: 71c330255a590e3605110f247cb9158e@85.193.128.15
CSeq: 102 INVITE
User-Agent: mywave VoIP Gateway by Christoph Stadlmann
Max-Forwards: 70
Date: Thu, 23 Aug 2007 06:27:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Privacy: none
P-Asserted-Identity: <sip:+43720440715@85.193.128.15:5060;transport=udp>
x-callrouting-priority: normal call
Content-Type: application/sdp
Content-Length: 242

v=0
o=root 32716 32716 IN IP4 85.193.128.15
s=session
c=IN IP4 85.193.128.15
t=0 0
m=audio 10768 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


So, as you can see, Peer A sends:
m=audio 4912 RTP/AVP 8 0 101
m=image 4914 udptl t38

and Peer B gets only:
m=audio 10768 RTP/AVP 8 101

In any further packet, like 183 session progress, no 'm=image' information is transmitted to peer B, and of course peer B does not respond with any 'm=image' information, so peer A (which is a Patton SmartNode) then refuses any UDPTL communication.

In my opinion, any header information should be passed to the callee, not only selected information.
Comments:By: Joshua C. Colp (jcolp) 2007-08-23 10:22:39

I assume t38 support is enabled in sip.conf? Can you please provide a *full* sip debug and not just snippets? and as for passing through all headers... Asterisk isn't a SIP proxy, it's a multiprotocol B2BUA PBX. There are just some things it can't pass through.
By: Christoph Stadlmann (cstadlmann) 2007-08-27 02:40:29

I just uploaded a 'clean' fulldebug log file. As you can see, during inital invite the Patton device (peer A) sends 'm=image 4936 udptl t38' (Line 28 and line 190 after authentication).

Although Asterisk 'knows' that the device requests UDPTL, the invite packet for peer B does not contain any 'm=image' information (line 456 and following lines). So Asterisk sends in it's response 183 to peer A just the audio information (line 567 and following lines). That confuses the Patton device because it thinks no T.38 is possible, and so after switch-over no communication takes place.

So as I said before, Asterisk does not pass all header information it get's from peer A to peer B.

Any thoughts?
By: Joshua C. Colp (jcolp) 2007-08-27 07:05:22

It is as I thought, all the T38 stuff is centered around having it done via reinvites and not having it in the initial INVITE.
By: Christoph Stadlmann (cstadlmann) 2007-09-14 00:42:03

Any updates here, file?
By: Olle Johansson (oej) 2007-11-05 15:17:05.000-0600

This is a feature request, since we do not support T.38 in the initial invite, only in re-invites.
By: Olle Johansson (oej) 2007-11-05 15:20:56.000-0600

I find this first invite really interesting. It's a two-channel invite with both audio and T38 at the same time. This is definitely not supported today.

Patton has a ton of configuration options for T.38, please check if you can disable this way of setting up the call and get it to use the ordinary method: First setup a normal call with ULAW/ALAW, then re-invite to T.38 fax?

Thanks.
By: Olle Johansson (oej) 2007-11-05 15:22:11.000-0600

Note to developers: Asterisk should answer and reject the second channel, the fax channel, media stream. I don't think the code can handle that today, since there's no "notion" of media streams, like if we where offered two audio streams and two video streams.
By: Christoph Stadlmann (cstadlmann) 2007-11-06 00:46:20.000-0600

After talking to Patton support, one can disable this feature by adding the following statement to the provisioning file (startup-config):

profile sip default
 no autonomous-transitioning

If you want to disable the feature via web interface, goto "SIP/Profile/default" and set "Media Stream Auto Transitioning" to "Disabled".

Anyway, if one could implement that feature in Asterisk I got another feature request which is related: Switching from T.38 back to Audio, which is also not possible with Asterisk.
By: Olle Johansson (oej) 2007-11-06 01:25:34.000-0600

Ok. The issue reported here is solved by reconfiguration of the device.

The other issue is already covered by other bug reports.

Thanks for reporting a possible bug. We will look into this feature in the future, but focus on bugs in 1.4 now :-)