[Freeswitch-users] SDP With T.38 in INVITE Problem
ivdreg ivdreg
ivdreg at gmail.com
Wed Feb 24 06:52:21 PST 2010
Hi Michael,
Thanks for clarifying. Unfortunately we don't live in prefect world. I was
fixed that by disabling T.38 in codec negotiation and everything works fine.
Thanks Again.
2010/2/24 Michael Jerris <mike at jerris.com>
> if you want clarity on this, read the rfc for sdp offer answer. You are
> not supposed to remove an m= line in an answer, if something is doing that,
> it is incorrect.
>
> Mike
>
> On Feb 22, 2010, at 11:49 AM, ivdreg ivdreg wrote:
>
> 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
>>
>>
> _______________________________________________
> 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/20100224/4555411c/attachment-0001.html
More information about the FreeSWITCH-users
mailing list