MediaProxyRelay - Media types do not match Error

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

MediaProxyRelay - Media types do not match Error

DanB-2
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.
"""

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


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: MediaProxyRelay - Media types do not match Error

Ruud Klaver
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: MediaProxyRelay - Media types do not match Error

DanB-2
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 <[hidden email]>
To: [hidden email]
Cc: [hidden email]
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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users