I see a problem here since the number of matched media streams from the
offer does not match with the number of matched media streams in reply
from asterisk (notice the m=audio 0 RTP/AVP 0 not present in the reply).
Please let me know if there are workarounds on this issue, or if this
could be a bug on asterisk side.
Best regards,
Mario Staphorst
Express yourself instantly with MSN Messenger! MSN Messenger
I see a problem here since the number of matched media streams from the
offer does not match with the number of matched media streams in reply
from asterisk (notice the m=audio 0 RTP/AVP 0 not present in the reply).
Please let me know if there are workarounds on this issue, or if this
could be a bug on asterisk side.
Best regards,
Mario Staphorst
------------------------------------------------------------------------
Express yourself instantly with MSN Messenger! MSN Messenger
<http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Posted: Wed May 27, 2009 1:59 pm Post subject: [asterisk-users] problem with T.38 media headers
Hi,
I think this is not completely right,
The scenario is:
Carrier ==> Asterisk 1.4 ==> T.38 ATA box.
What happends is that the header disappears within the Asterisk server and is not reaching the ATA.
I think the SDP headers should be passed through in all circumstances, even if Asterisk 1.4 is only doing T.38 passthrough?
This is not a problem. Asterisk is under no obligation to offer an
audio codec in return.
mario staphorst wrote:
> Hi Guys,
>
> Something I have noticed while dealing with T.38 and re-invites in
> Asterisk 1.4.22.
>
> I have a provider who re-invites with the following sdp (message flow
> PROVIDER_EQPMT -> ASTERISK):
>
> """
> .
> 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 asterisk in this case is:
>
> """
> .
> v=0.
> o=root 3484 3485 IN IP4 CONN_IP_ASTERISK.
> s=session.
> c=IN IP4 CONN_IP_ASTERISK.
> 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.
> """
>
> I see a problem here since the number of matched media streams from the
> offer does not match with the number of matched media streams in reply
> from asterisk (notice the m=audio 0 RTP/AVP 0 not present in the reply).
>
> Please let me know if there are workarounds on this issue, or if this
> could be a bug on asterisk side.
>
> Best regards,
>
> Mario Staphorst
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Posted: Wed May 27, 2009 2:20 pm Post subject: [asterisk-users] problem with T.38 media headers
mario staphorst wrote:
Quote:
Carrier ==> Asterisk 1.4 ==> T.38 ATA box.
What happends is that the header disappears within the Asterisk server
and is not reaching the ATA.
I think the SDP headers should be passed through in all circumstances,
even if Asterisk 1.4 is only doing T.38 passthrough?
Asterisk is not a proxy; SIP signaling is never 'passed through'; the
two legs of a call are completely separate and Asterisk bridges them
together when necessary.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Posted: Wed May 27, 2009 3:25 pm Post subject: [asterisk-users] problem with T.38 media headers
Hi Kevin,
Thank you for your reply.
I understand that Asterisk is not a SIP proxy, but shouldnt this header be passed on in order to provide proper T.38 passthrough support in this case?
As far as i can see is this header really needed to make the T.38 connection successfull, when i setup the call directly to the ATA the reinvite is going fine.
> Carrier ==> Asterisk 1.4 ==> T.38 ATA box.
>
> What happends is that the header disappears within the Asterisk server
> and is not reaching the ATA.
> I think the SDP headers should be passed through in all circumstances,
> even if Asterisk 1.4 is only doing T.38 passthrough?
Asterisk is not a proxy; SIP signaling is never 'passed through'; the
two legs of a call are completely separate and Asterisk bridges them
together when necessary.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Posted: Wed May 27, 2009 8:18 pm Post subject: [asterisk-users] problem with T.38 media headers
mario staphorst wrote:
Quote:
Thank you for your reply.
I understand that Asterisk is not a SIP proxy, but shouldnt this header
be passed on in order to provide proper T.38 passthrough support in this
case?
As far as i can see is this header really needed to make the T.38
connection successfull, when i setup the call directly to the ATA the
reinvite is going fine.
T.38 negotiation has already been improved in later releases than what
you are using, so I'd suggest upgrading to 1.4.25 (or 1.4.26-rc1) before
continuing, as it is possible that your issue has already been fixed.
However, there are still areas we've identified where our T.38
negotiation needs some additional work, and we'll be trying to address
those shortly.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
