[asterisk-bugs] [Asterisk 0010532]: Some information from INVITE of Peer A not passed to INVITE of Peer B

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10532 
====================================================================== 
Reported By:                cstadlmann
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10532
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 79998 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-23-2007 01:32 CDT
Last Modified:              11-05-2007 15:22 CST
====================================================================== 
Summary:                    Some information from INVITE of Peer A not passed to
INVITE of Peer B
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 at 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 at voip.mywave.at
From: sip:440715 at 83.65.56.172:5060;tag=f69b00ed276775f
Call-ID: 7174400498466f716e592f9eadf1efdd at 83.65.56.172
CSeq: 1572731910 INVITE
Route: <sip:voip.mywave.at;lr>
Supported: timer
Contact: sip:440715 at 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 at 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 at 212.31.71.22 SIP/2.0
Via: SIP/2.0/UDP 85.193.128.15:5060;branch=z9hG4bK2225ce61
From: "+43720440715" <sip:+43720440715 at 85.193.128.15>;tag=as73fa5fb6
To: <sip:073261066060 at 212.31.71.22>
Contact: <sip:+43720440715 at 85.193.128.15>
Call-ID: 71c330255a590e3605110f247cb9158e at 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 at 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.
====================================================================== 

---------------------------------------------------------------------- 
 oej - 11-05-07 15:22  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-05-07 15:22  oej            Note Added: 0073147                          
======================================================================