[Freeswitch-dev] FS doesn't update rtp port when sdp changed in 200OK response for invite message.

[Michael Collins]

Can you update to latest trunk and see if this still occurs? There have been
many updates since pre9.
Thanks,
MC

2009/12/24 Lei Tang <lei.tlfly at gmail.com>

> Merry Christmas everyone!
>
> I'm using FS 1.0.5pre9, I think there is a bug in mod_sofia when SDP
> changed in 200 OK response for INVITE message,
>
> the scenario is :
> A(FreeSwitch)                      B
>       ------INVITE ------->
>       <----100 Tring--------
>       <----180 Ring --------   with sdp m=audio 55066 RTP/AVP 0 120  c=IN
> IP4 10.36.143.76
>       <----UPDATE -------    with sdp m=audio 45486 RTP/AVP 0 120  c=IN IP4
> 10.36.143.76
>       -----200 OK  ------>     response for UPDATE message
>       <---- 200 OK--------     response for INVITE message,  with sdp
> m=audio 45486 RTP/AVP 0 120  c=IN IP4 10.36.143.76
>       --------ACK --------->
>
> The problem is, B changed the rtp port in UPDATE message and "200 OK"
> response message, but FS didn't do update, so it still send and receive data
> from port 55066.
> I read the mod_sofia source code and debug log, I found that  when get
> 200OK response ,mod_sofia should update rtp session when sdp information is
> different of the the pre sdp received in 180 ring response,
> I'm using proxy_media mode, and I think there is the same problem in normal
> mode.
>
> here is the outbound channel state change log
> ==============================
> entering state [received][100]
> entering state [calling][0]
> entering state [proceeding][180]
> entering state [proceeding][200]
> entering state [completing][200]
> entering state [ready][200]
> entering state [completed][200]
> entering state [ready][200]
>
>
> The problem is in state [proceeding][200], The code is as follow:
> sofia.c line 3876
>                 if (switch_channel_test_flag(channel, CF_PROXY_MEDIA)) {
>                     if (sofia_glue_activate_rtp(tech_pvt, 0) !=
> SWITCH_STATUS_SUCCESS) {
>                         goto done;
>                     }
>                 }
>
> Since the rtp session is initialized when 180 RING response received,
> sofia_glue_activate_rtp will return SWITCH_STATUS_SUCCESS without change any
> thing,
> So, I think the code should be as follow
>
> 3876                 if (switch_channel_test_flag(channel, CF_PROXY_MEDIA))
> {
> 3877                     if (tech_pvt->rtp_session &&
> !is_dup_sdp){
>
> 3878                         sofia_set_flag_locked(tech_pvt,
> TFLAG_REINVITE);
> 3879                         if
> (sofia_glue_tech_proxy_remote_addr(tech_pvt) != SWITCH_STATUS_SUCCESS ||
> sofia_glue_activate_rtp(tec     h_pvt, 0) != SWITCH_STATUS_SUCCESS)
> {
>
> 3880                             sofia_clear_flag_locked(tech_pvt,
> TFLAG_REINVITE);
> 3881                             goto
> done;
>
> 3882
> }
>
> 3883                         sofia_clear_flag_locked(tech_pvt,
> TFLAG_REINVITE);
> 3884
> }else{
>
> 3885                         if (sofia_glue_activate_rtp(tech_pvt, 0) !=
> SWITCH_STATUS_SUCCESS) {
> 3886                             goto
> done;
>
> 3887
> }
>
> 3888
> }
>
> 3889                 }
>
> When get 200OK reponse and sdp is changed, we should update remote port and
> set reinvite flag before call  sofia_glue_activate_rtp.
>
> Because I'm not so familiy with sofia and mod_sofia's source code, this
> code is only for PROXY MEDIA mode and doesn't check for codec changed.(in my
> scenario, only the remote port and ip are changed).
>
> Could some fs dev check this problem, and give a offical patch?
>
> BTW, I guess maybe mod_sofia is just ignore UPDATE message too. (just
> ignore it if I was wrong)
>
> Best Regards
> --
> Lei.Tang
> lei.tlfly at gmail.com
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20091224/26a1674e/attachment.html