Hi Ruud, many thanks for so fast answer. Looks like I am hopeless ;-).
Will try to get the info to the asterisk folks then. Wish you a nice day! DanB -----Original Message----- From: Ruud Klaver <[email protected]> To: [email protected] Cc: [email protected] Subject: Re: [OpenSIPS-Users] MediaProxyRelay - Media types do not match Error Date: Tue, 26 May 2009 19:39:36 +0200 Hi, On 26 May 2009, at 15:03, Dan-Cristian Bogos wrote: > Hey Guys, > > something I have noticed while dealing with T.38. > > I have a provider who re-invites with the following sdp: > > """ > . > v=0. > o=SIP_5F9 123456 654322 IN IP4 CONN_IP_PROVIDER. > s=-. > c=IN IP4 CONN_IP_PROVIDER. > t=0 0. > m=audio 0 RTP/AVP 0. > m=image 26858 udptl t38. > a=T38FaxMaxBuffer:288. > a=T38FaxRateManagement:transferredTCF. > a=T38FaxUdpEC:t38UDPRedundancy. > """ What this re-INVITE means is "Stream 0 is audio but is now disabled (effectively removed). Stream 1 is T.38 FAX, and as this wasn't in the previous SDP, this is a proposal to add this stream." > > The answer coming from re-invited device (which happens to be an > asterisk right now): > > """ > . > v=0. > o=root 3484 3485 IN IP4 CONN_IP_ENDPOINT. > s=session. > c=IN IP4 CONN_IP_ENDPOINT. > t=0 0. > m=image 4653 udptl t38. > a=T38FaxVersion:0. > a=T38MaxBitRate:9600. > a=T38FaxRateManagement:transferredTCF. > a=T38FaxMaxBuffer:200. > a=T38FaxMaxDatagram:200. > a=T38FaxUdpEC:t38UDPRedundancy. > """ > > The answer coming from the endpoint will produce an exception in > mediaproxy, therefore sending wrong conn_ip. I assume mediaproxy > considers the "on hold" audio as update to the existing media type > "m=audio 0 RTP/AVP 0.", instead of updating the session media type to > the new "m=image 26858 udptl t38.". Is this what you guys expect to > do? > > [RelayClientProtocol,client] exceptions.ValueError: Media types do > not match: "audio" and "image" > > Thanks in advance for any kind of advice. > > DanB The answer is incorrect, because 1) the number of media streams don't match and 2) the media type of stream 0 is different from the proposal. Astrerisk is behaving very wrongly here, since m= lines always should be matched up based on position in the SDP. So there is no way mediaproxy can know which m= line in the answer matches which m= line in the proposal. Ruud Klaver AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
