[Serdev] two session on rtpproxy with video?

[Rodrigo Frez]

by the way I like to volunteer to test any improvements. I have many configurations
on my network for testing:

natclient<->publicclient
natclient<->natclient

and so...
>In fact in previous post i mentioned that in nathelper's extract_media_port()
>(used for fix_nated_sdp(2)), the "m=audio" was hardcoded..., i try with
>this change, but nothing :
>
>#######################
>if (mediaport->len < 7 || (memcmp(mediaport->s, "audio", 5) != 0 && memcmp(mediaport->s,
>"video", 5) != 0) || !isspace((int)mediaport->s[5])) {
>       LOG(L_ERR, "ERROR: extract_mediaport: can't parse `m=' in SDP\n");
>       return -1;
>}
>#######################
>
>	instead of:
>
>#######################
>if (mediaport->len < 7 || memcmp(mediaport->s, "audio", 5) != 0 ||
>!isspace((int)mediaport->s[5])) {
>       LOG(L_ERR, "ERROR: extract_mediaport: can't parse `m=' in SDP\n");
>       return -1;
>}
>#######################
>
>>You did explain wel.l. The second m= line for video is not yet handled.
>
>>  See previous email on the list.
>>
>>I plan to add this functionality but I first want to check with the
>>other developers about this. Stay tuned.
>>
>>
>>
>>On 19 Jan 2004, at 19:26, Rodrigo Frez wrote:
>>
>>> if video are present and we want to pass through the rtpproxy, this
>>> means
>>> that we have two open sessions?. If so, maybe the sdp flag inserted
>>> when
>>> executing force_rtp_proxy, does not let the video pass through the
>>> proxy.
>>> I use ethereal to see what happen to video packets and sip related
>>> messages,
>>> and yes, the sdp headers are changed, and the IP is rewrited, but when
>>
>>> the
>>> udp packets of video begin to come from a client, ethereal show me a
>
>>> destination
>>> unreacheable message, due to the port on the server...
>>>
>>> So:
>>>
>>>     Client->NAT->SER&RTPPROXY
>>>                            *
>>>
>>> the video packets in (*) have by destiny somo port on the server that
>
>>> is
>>> not ready to listen, and I think is to due that the rtpproxy is not
>>> listening,
>>> because never open a session to handle the video...
>>>
>>> PS: I hope I explaine it well...
>>>
>>> _______________________________________________
>>> Serdev mailing list
>>> serdev at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serdev
>>>
>>
>
>
>_______________________________________________
>Serdev mailing list
>serdev at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev