err, no, I tried upgrading from r11000 to r12669 yesterday, but starting seeing crashing, so I have a jira open. currently I'm back on r11000. http://jira.freeswitch.org/browse/FSCORE-338 Gabe Brian West wrote:

Are you on SVN trunk 12694?

/b

On Mar 20, 2009, at 4:28 PM, Gabriel Kuri wrote:

...

hey folks, I'm trying to configure PCMU fallback for T.38.

The originating endpoint (Linksys SPA-2102) sends an INVITE to FS with G729 and PCMU in the sdp. the INVITE to the provider includes G729 and PCMU as part of the sdp as well (absolute_codec_string=G729,PCMU) ...

m=audio 16458 RTP/AVP 18 0 100 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:100 NSE/8000 a=fmtp:100 192-193 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20

once the FAX tone is detected on the PSTN side, FS receives a T.38 re-INVITE from the provider and FS sends back a 488/Not Acceptable (proxy_media=false). at that point the provider than attempts fallback to PCMU with another reINVITE ...

m=audio 16816 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20

immediately after the PCMU reINVITE, FS closes the channel and the text below is in the FS logs. given the SPA-2102 included PCMU in the original INVITE, even though it was the second preferred codec, shouldn't FS fallback to using PCMU if it was re-INVITEd with PCMU by the provider? It seems like it's not passing the PCMU Re-INVITE back to the endpoint (SPA-2102), since it originally negotiated G729 with the SPA2102 as that was the 1st codec in the sdp, but trying to transcode between the two (G729 and PCMU)?

2009-03-20 01:19:58 [DEBUG] sofia_glue.c:2407 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[G729:18:8000] 2009-03-20 01:19:58 [DEBUG] sofia_glue.c:2371 sofia_glue_negotiate_sdp() Set 2833 dtmf payload to 101 2009-03-20 01:19:58 [DEBUG] sofia_glue.c:2407 sofia_glue_negotiate_sdp() Audio Codec Compare [telephone-event:101:8000]/[G729:18:8000] 2009-03-20 01:19:58 [DEBUG] sofia_glue.c:2407 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[PCMU:0:8000] 2009-03-20 01:19:58 [DEBUG] sofia_glue.c:1550 sofia_glue_tech_set_codec() Changing Codec from G729 to PCMU 2009-03-20 01:19:58 [DEBUG] sofia_glue.c:1601 sofia_glue_tech_set_codec() Set Codec sofia/cedarwireless.net/1XXXXXXXXXX@1.1.1.1 PCMU/8000 20 ms 160 samples 2009-03-20 01:19:58 [DEBUG] sofia_glue.c:1811 sofia_glue_activate_rtp() Audio params are unchanged for sofia/cedarwireless.net/1XXXXXXXXXX@1.1.1.1 . 2009-03-20 01:19:58 [DEBUG] sofia.c:2896 sofia_handle_sip_i_state() Processing Reinvite 2009-03-20 01:19:58 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofia/cedarwireless.net/1XXXXXXXXXX@1.1.1.1 entering state [completed] 2009-03-20 01:19:58 [DEBUG] switch_core_io.c:655 switch_core_session_write_frame() sofia/cedarwireless.net/1XXXXXXXXXX@1.1.1.1 receive message [SWITCH_MESSAGE_INDICATE_TRANSCODING_NECESSARY] 2009-03-20 01:19:58 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-03-20 01:19:58 [ERR] switch_core_io.c:723 switch_core_session_write_frame() Codec G.729 decoder error!

Thanks,

Gabe

_______________________________________________ Freeswitch-users mailing list Freeswitch-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

OK, I'll give it a try and report back. Gabe Brian West wrote:

Make current and try again... I haven't seen this crash you have seen... if you can run sippcapdump and get the packets that would help also.

Thanks, /b

On Mar 20, 2009, at 4:41 PM, Gabriel Kuri wrote:

...

err, no, I tried upgrading from r11000 to r12669 yesterday, but starting seeing crashing, so I have a jira open. currently I'm back on r11000.

http://jira.freeswitch.org/browse/FSCORE-338

Gabe

------------------------------------------------------------------------

_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

This part is interesting, and the subject of a discussion we had recently. A number of systems try that second re-invite after a 488, but the SIP specs say the call is pretty much dead after the 488 message is exchanged. Are they just hoping that maybe the other end will be non-compliant enough to keep the call alive, and recover its media mode, or haven't they read the specs?

I think they're hoping the other end is willing to recover it's media mode rather than fail the call. I had no idea the call is technically dead after the 488. Honestly, it would be nice if the call would still be recoverable after that 488 on the T.38 ReINVITE, in order to try and negotiate PCMU to try and keep the FAX going, but if that's not how it's supposed to work, I'd rather follow the spec. So for now I've disabled T.38 completely on both the SPA side and I had the carrier disable it on my trunk, so they won't try a T.38 reinvite. Instead they're trying a PCMU ReINVITE and the problem I'm seeing is that if the carrier reINVITEs PCMU after the call initially started out as G729, FS fails the call, because it seems to be trying to transcode between G729 and PCMU, rather than pass the PCMU reINVITE through to the other leg. 2009-03-31 00:30:50 [DEBUG] sofia_glue.c:1550 sofia_glue_tech_set_codec() Changing Codec from G729 to PCMU 2009-03-31 00:30:50 [DEBUG] sofia_glue.c:1601 sofia_glue_tech_set_codec() Set Codec sofia/cedarwireless.net/1909XXXXXXX@65.98.2 36.38 PCMU/8000 20 ms 160 samples 2009-03-31 00:30:50 [DEBUG] sofia_glue.c:1811 sofia_glue_activate_rtp() Audio params are unchanged for sofia/cedarwireless.net/ 1909XXXXXXX@65.98.236.38. 2009-03-31 00:30:50 [DEBUG] sofia.c:2896 sofia_handle_sip_i_state() Processing Reinvite 2009-03-31 00:30:50 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofia/cedarwireless.net/1909XXXXXXX@65.98.236.38 en tering state [completed] 2009-03-31 00:30:50 [DEBUG] switch_core_io.c:655 switch_core_session_write_frame() sofia/cedarwireless.net/1909XXXXXXX@65.98.23 6.38 receive message [SWITCH_MESSAGE_INDICATE_TRANSCODING_NECESSARY] 2009-03-31 00:30:50 [ERR] mod_g729.c:145 switch_g729_decode() This codec is only usable in passthrough mode! 2009-03-31 00:30:50 [ERR] switch_core_io.c:723 switch_core_session_write_frame() Codec G.729 decoder error! I have inherit_codec=true, set in the dialplan and disable-transcoding=true set in the sofia profile, which is what I thought would do the trick, but it doesn't seem to be doing anything, FS is still trying to transcode between G729 and PCMU. Is there something I'm missing to get the PCMU ReINVITE from one of the legs to passthrough to the other leg? Does this work only in proxy_media or bypass_media modes? I am testing this with the latest rev of trunk as well. Thanks, Gabe

On Fri, Mar 20, 2009 at 7:46 PM, Steve Underwood <steveu@coppice.org> wrote:

Gabriel Kuri wrote:

...

once the FAX tone is detected on the PSTN side, FS receives a T.38 re-INVITE from the provider and FS sends back a 488/Not Acceptable (proxy_media=false). at that point the provider than attempts fallback to PCMU with another reINVITE ...

This part is interesting, and the subject of a discussion we had recently. A number of systems try that second re-invite after a 488, but the SIP specs say the call is pretty much dead after the 488 message is exchanged. Are they just hoping that maybe the other end will be non-compliant enough to keep the call alive, and recover its media mode, or haven't they read the specs?

Steve

I am interested in this later document. From what I can see there is rfc3261 and at least one other RFC (and one draft that I have found after about 30 minutes of searching) that support that a 488 response can be recovered from when it is a response to a reinvite (ie, the dialog is already in place and there is something to fall back to). Where does it say that a 488 has to end a dialog? From what I understand there are not any 4xx codes that by themselves terminate a dialog (except where it terminates the last leg of a call -- much like unlink() in unix). draft-ietf-sipping-realtimefax-01 says:

6.2. Unsuccessful T.38 fax scenario -

- 488/606 rsp & G.711 fallback

This section represents an unsuccessful SIP T.38 fax call: when the emitting gateway does not support T.38 fax relay, it SHOULD respond with either a ��488 Not Acceptable Here�� response or a ��606 Not

Acceptable�� response to indicate that some aspects of the session description are not acceptable. The terminating gateway SHOULD react by proposing a fallback to G.711 fax pass-through with special

codec characteristics - -silence suppression OFF. The message details in this section make use of the generic SDP attribute silenceSupp defined in RFC3108

rfc3261 section 3 says:

During the session, either Alice or Bob may decide to change the

characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a

new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as

488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section

14.

section 14.1 says:

If a UA receives a non-2xx final response to a re-INVITE, the session

parameters MUST remain unchanged, as if no re-INVITE had been issued. Note that, as stated in Section 12.2.1.2, if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the re-

INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will terminate the dialog.

rfc4497 says:

8.5. Request to Change Media Characteristics

If after a call has been successfully established the gateway receives a SIP INVITE request to change the media characteristics of the call in a way that would be incompatible with the bearer capability in use within the PISN, the gateway SHALL send back a SIP 488 (Not Acceptable Here) response and SHALL NOT change the media characteristics of the existing call.