[OpenSIPS-Users] MediaProxyRelay - Media types do not match Error

[Dan-Cristian Bogos]

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 <ruud at ag-projects.com>
To: danb at sms4sip.com
Cc: users at lists.opensips.org
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