[Freeswitch-users] SDP With T.38 in INVITE Problem

ivdreg ivdreg ivdreg at gmail.com
Mon Feb 22 08:49:07 PST 2010


Hi Michael,

As I said in a previous mails I know exactly what is happening.
In working setup:

ITSP ---> YATE (GW - Frontend) ---> FreeSwitch (routing server/xml_curl)
---> YATE (GW - SIP Interop) ---> OpenSIPS ---> Subscriber.

I prefer to change YATE (GW - Frontend) and YATE (GW - SIP Interop) with
FreeSwitch for some reasons. The problem is:

INVITE comes from ITSP and goes to subscriber via OpenSIPS. INIVITE between
FreeSwitch (routing server) and YATE (GW - SIP Interop) contains SDP:
m=audio 21108 RTP/AVP 18 4 8 0
c=IN IP4 10.10.1.110
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
m=image 21108 udptl t38
c=IN IP4 10.10.1.110
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxUdpEC:t38UDPRedundancy
a=T38FaxRateManagement:
transferredTCF

And reply 200 OK contains in SDP:
*m=audio 34788 RTP/AVP 8*
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20

Reply 200 OK SDP between YATE (GW - SIP Interop) and OpenSIPS contains in
SDP:
*m=audio 16330 RTP/AVP 8*
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
*m=image 0 udptl 19*

In this case everything works fine. Line *m=image 0 udptl 19 *is removed by
YATE.
But same test with FreeSWITCH on the place of YATE (GW - SIP Interop) *"m=image
0 udptl 19" *call brakes as you can see in my first mail.

I don't want to compare or discus YATE and FS functionality or something
else. I just see difference in behavior and because I'm not a big expert
don't know witch implementation is more accurate according standards. And
second: Is it impossible for me to upgrade all CPE so only thing I can do is
to fix it on server side. That is because I ask for a help.


Thanks to all.


2010/2/22 Michael Jerris <mike at jerris.com>

> if you want to see what is going on, crank up the debug in freeswitch and
> sofia and you should see exactly what is going on.
>
> Mike
>
>
> On Mon, Feb 22, 2010 at 10:11 AM, ivdreg ivdreg <ivdreg at gmail.com> wrote:
>
>> Hi Michael,
>>
>> This happens when ONLY IF initial INVITE is coming with T.38 from a GW
>> (this is ITSP equipment and I don't know vendor) to our SIP subscribers with
>> ATCOM ATA and IP Phone. We use now in production YATE for terminating and
>> originating GWs to ITSPs and FS as main routing logic (backend). We want to
>> switch YATE to FS for a GW also but we faced this problem. This not happens
>> if initial INVITE nave no T.38 offered and later re-INVITE with T.38 with
>> valid SDP port.
>>
>> Thanks
>>
>> 2010/2/22 Michael Jerris <mike at jerris.com>
>>
>>>  If the endpoint does not correctly follow the sdp o/a model its not
>>> going to work.  This is not a "problem" with the sofia library, this is
>>> intended behavior and what we are supposed to do.  What is the device?
>>>
>>> Mike
>>>
>>> On Feb 22, 2010, at 7:48 AM, ivdreg ivdreg wrote:
>>>
>>> Hi All,
>>>
>>> Actually while seeking the solution in internet I see some people having
>>> this problem with sofia library. I'm not sure that SIP reply in this case
>>> contains a valid SDP (I think that teminating endpoint is broken) but in my
>>> opinion if we have at least one valid media type in SDP (video, audio, image
>>> ...) call must be established. Can someone comment and/or help me with this
>>> issue.
>>>
>>> Regards.
>>>
>>> 2010/2/19 ivdreg ivdreg <ivdreg at gmail.com>
>>>
>>>> Hi all,
>>>>
>>>> Dose someone have a problem that if there T.38 in coming from gateway
>>>> FreeSwitch drops the call because of media error ? As I see from log only
>>>> T.38 port is zero and SDP has also media port. Is it possible to configure
>>>> FS to do not break a call but if media is OK.
>>>>
>>>> 2010-02-19 12:26:14.305244 [NOTICE] switch_channel.c:666 New Channel
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065[6cd9f634-411d-df11-99ca-003048bb99cc]
>>>> 2010-02-19 12:26:14.305244 [DEBUG] mod_sofia.c:3369 (sofia/backend/
>>>> XXXXXXXXXX at 10.10.1.110:7065) State Change CS_NEW -> CS_INIT
>>>> 2010-02-19 12:26:14.305244 [DEBUG] switch_core_session.c:1018 Send
>>>> signal sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 [BREAK]
>>>> 2010-02-19 12:26:14.305244 [DEBUG] switch_core_state_machine.c:314
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) Running State Change
>>>> CS_INIT
>>>> 2010-02-19 12:26:14.305244 [DEBUG] switch_core_state_machine.c:338
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) State INIT
>>>> 2010-02-19 12:26:14.305244 [DEBUG] mod_sofia.c:83 sofia/backend/
>>>> XXXXXXXXXX at 10.10.1.110:7065 SOFIA INIT
>>>> 2010-02-19 12:26:14.305244 [DEBUG] sofia_glue.c:1377 sofia/backend/
>>>> XXXXXXXXXX at 10.10.1.110:7065 Patched SDP
>>>> ---
>>>> v=0
>>>> o=- 3779949069 5166785777234550622 IN IP4 206.132.232.212
>>>> s=session
>>>> t=0 0
>>>> m=audio 21108 RTP/AVP 18 4 8 0
>>>> c=IN IP4 10.10.1.110
>>>> a=rtpmap:18 G729/8000
>>>> a=rtpmap:4 G723/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:0 PCMU/8000
>>>> m=image 21108 udptl t38
>>>> c=IN IP4 10.10.1.110
>>>> a=T38FaxVersion:0
>>>> a=T38MaxBitRate:14400
>>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>> a=T38FaxRateManagement:transferredTCF
>>>>
>>>> +++
>>>> v=0
>>>> o=- 3779949069 5166785777234550622 IN IP4 206.132.232.212
>>>> s=session
>>>> t=0 0
>>>> m=audio 17058 RTP/AVP 18 4 8 0
>>>> c=IN IP4 10.10.1.100
>>>> a=rtpmap:18 G729/8000
>>>> a=rtpmap:4 G723/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:0 PCMU/8000
>>>> m=image 17058 udptl t38
>>>> c=IN IP4 10.10.1.100
>>>> a=T38FaxVersion:0
>>>> a=T38MaxBitRate:14400
>>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>> a=T38FaxRateManagement:transferredTCF
>>>>
>>>> 2010-02-19 12:26:14.305244 [DEBUG] mod_sofia.c:117 (sofia/backend/
>>>> XXXXXXXXXX at 10.10.1.110:7065) State Change CS_INIT -> CS_ROUTING
>>>> ......
>>>> 2010-02-19 12:26:21.255201 [DEBUG] sofia.c:4135 Remote SDP:
>>>> v=0
>>>> o=FreeSWITCH 1266548331 1266548332 IN IP4 10.10.1.110
>>>> s=FreeSWITCH
>>>> c=IN IP4 10.10.1.110
>>>> t=0 0
>>>> *m=audio 26850 RTP/AVP 8*
>>>> a=rtpmap:8 PCMA/8000
>>>> a=silenceSupp:off - - - -
>>>> a=ptime:20
>>>> *m=image 0 udptl 19*
>>>>
>>>> 2010-02-19 12:26:21.255201 [DEBUG] sofia.c:4124 Channel sofia/backend/
>>>> XXXXXXXXXX at 10.10.1.110:7065 entering state [ready][200]
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_channel.c:2285 Send signal
>>>> sofia/backend/YYYYYYYYYY at 10.10.1.110 [BREAK]
>>>> 2010-02-19 12:26:21.255201 [NOTICE] sofia.c:4668 Channel [sofia/backend/
>>>> XXXXXXXXXX at 10.10.1.110:7065] has been answered
>>>> 2010-02-19 12:26:21.255201 [DEBUG] sofia_glue.c:2288 Set Codec
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 PROXY/8000 20 ms 160 samples
>>>> *2010-02-19 12:26:21.255201 [DEBUG] sofia_glue.c:2571 PROXY AUDIO RTP
>>>> [sofia/backend/XXXXXXXXXX at 10.10.1.110:7065] 10.10.1.100:17058->
>>>> 10.10.1.110:0 codec: 0 ms: 20
>>>> 2010-02-19 12:26:21.255201 [ERR] sofia_glue.c:2879 AUDIO RTP REPORTS
>>>> ERROR: [Missing remote port]
>>>> 2010-02-19 12:26:21.255201 [NOTICE] sofia_glue.c:2880 Hangup
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 [CS_CONSUME_MEDIA]
>>>> [DESTINATION_OUT_OF_ORDER]*
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_channel.c:2063 Send signal
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 [KILL]
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_session.c:1018 Send
>>>> signal sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 [BREAK]
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:314
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) Running State Change
>>>> CS_HANGUP
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:499
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) State HANGUP
>>>> 2010-02-19 12:26:21.255201 [DEBUG] mod_sofia.c:411 Channel
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 hanging up, cause:
>>>> DESTINATION_OUT_OF_ORDER
>>>> 2010-02-19 12:26:21.255201 [DEBUG] mod_sofia.c:454 Sending BYE to
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:46
>>>> sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 Standard HANGUP, cause:
>>>> DESTINATION_OUT_OF_ORDER
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:499
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) State HANGUP going to sleep
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:333
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) State Change CS_HANGUP ->
>>>> CS_REPORTING
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_session.c:1018 Send
>>>> signal sofia/backend/XXXXXXXXXX at 10.10.1.110:7065 [BREAK]
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:314
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) Running State Change
>>>> CS_REPORTING
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_ivr_originate.c:3185 Originate
>>>> Resulted in Error Cause: 27 [DESTINATION_OUT_OF_ORDER]
>>>> 2010-02-19 12:26:21.255201 [INFO] mod_dptools.c:2353 Originate Failed.
>>>> Cause: DESTINATION_OUT_OF_ORDER
>>>> 2010-02-19 12:26:21.255201 [DEBUG] switch_core_state_machine.c:590
>>>> (sofia/backend/XXXXXXXXXX at 10.10.1.110:7065) State REPORTING
>>>>
>>>>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100222/e5b81361/attachment-0002.html 


More information about the FreeSWITCH-users mailing list