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

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
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:                     resolved
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:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             08-23-2007 01:32 CDT
Last Modified:              11-06-2007 01:25 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.
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-06-07 01:25  oej            Status                   assigned => resolved
11-06-07 01:25  oej            Resolution               open => no change
required
======================================================================