[sip-comm-dev] sip communicator rtp issue


#1

Hi,

Trying to develop different applciation from sip communicator, I´ve noticed
that even if I specify a different port for the local and the remote
addresses, when transmitting audio via RTP to the remote party, it uses the
same port for sending the stream in the local machine than the remote one
the remote party stablishes via the sdp description. This is the scenario:

MyPC, for examples, chooses to use port 42050 for RTP , and the remote one
chooses 32060.

When using for receiving, no problem, the connection is as follows:

42050 <------------------ 32060

but if i try to send audio, it just won´t do it like this:

42050 -----------------> 32060

I found this issue in the past but solved it making the connection like
this, using the same port as the stated in the sdp description from the
remote party:

32060 -----------------> 32060 , and that way it worked fine, but now i
would like to do the connection properly, like the way i described.

Is this a known issue with sip-communicator or jmf? I would really
appreciate your help.

Thanks for your time.

borja


#2

Hi Borja, all,

This is indeed a bit tricky, and I agree that the way it was so far implemented in the SIP Communicator is quite clumsy.

RFCs, in general, don't say anything about ports where data should be sent from. Yet, ideally, when RTP is concerned (especially in a VoIP setup) a client would have to transmit from the same port that it receives on, so that packets could go successfully through all firewalls that the remote party is behind.

The problem is that when beginning transmission, a client is not certain of having already received anything, and it has therefore no clue as to where to send from. The way pre1.0 is "dealing" with this was - "ok let's just send and receive everything on a preconfigured port so that in and out bound packets have a matching port number", which is of course quite naive.

We'd need to find out a better way to do that.

Any suggestions, anyone?

Emil

Borja Gonzalez wrote:

···

Hi,

Trying to develop different applciation from sip communicator, I�ve noticed that even if I specify a different port for the local and the remote addresses, when transmitting audio via RTP to the remote party, it uses the same port for sending the stream in the local machine than the remote one the remote party stablishes via the sdp description. This is the scenario:

MyPC, for examples, chooses to use port 42050 for RTP , and the remote one chooses 32060.

When using for receiving, no problem, the connection is as follows:

42050 <------------------ 32060

but if i try to send audio, it just won�t do it like this:

42050 -----------------> 32060

I found this issue in the past but solved it making the connection like this, using the same port as the stated in the sdp description from the remote party:

32060 -----------------> 32060 , and that way it worked fine, but now i would like to do the connection properly, like the way i described.

Is this a known issue with sip-communicator or jmf? I would really appreciate your help.

Thanks for your time.

borja

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

So, considering that that's how it is, that we have to receive in the same
port that they send us the rtp streams from,
thinking about a conferencing application, is it possible to have multiple
streams being received in the same local port from different endpoints? and
of course, hearing the audio and sending it correctly?

because testing with the sip communicator code, i've noticed that i cannot
establish two successful rtp sessions at the same time, is that my fault or
is it how it goes?

thanks for your help,

borja

···

On 11/16/05, Emil Ivov <emil_ivov@yahoo.com> wrote:

Hi Borja, all,

This is indeed a bit tricky, and I agree that the way it was so far
implemented in the SIP Communicator is quite clumsy.

RFCs, in general, don't say anything about ports where data should be
sent from. Yet, ideally, when RTP is concerned (especially in a VoIP
setup) a client would have to transmit from the same port that it
receives on, so that packets could go successfully through all firewalls
that the remote party is behind.

The problem is that when beginning transmission, a client is not certain
of having already received anything, and it has therefore no clue as to
where to send from. The way pre1.0 is "dealing" with this was - "ok
let's just send and receive everything on a preconfigured port so that
in and out bound packets have a matching port number", which is of
course quite naive.

We'd need to find out a better way to do that.

Any suggestions, anyone?

Emil

Borja Gonzalez wrote:
> Hi,
>
> Trying to develop different applciation from sip communicator, I´ve
> noticed that even if I specify a different port for the local and the
> remote addresses, when transmitting audio via RTP to the remote party,
> it uses the same port for sending the stream in the local machine than
> the remote one the remote party stablishes via the sdp description. This
> is the scenario:
>
> MyPC, for examples, chooses to use port 42050 for RTP , and the remote
> one chooses 32060.
>
> When using for receiving, no problem, the connection is as follows:
>
> 42050 <------------------ 32060
>
> but if i try to send audio, it just won´t do it like this:
>
> 42050 -----------------> 32060
>
> I found this issue in the past but solved it making the connection like
> this, using the same port as the stated in the sdp description from the
> remote party:
>
> 32060 -----------------> 32060 , and that way it worked fine, but now i
> would like to do the connection properly, like the way i described.
>
> Is this a known issue with sip-communicator or jmf? I would really
> appreciate your help.
>
> Thanks for your time.
>
> borja

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

So, considering that that's how it is, that we have to receive in the same port that they send us the rtp streams from,

Not exactly. We have to send from the same port that they send to and to the same port that they send from. In other words, imagine that we are B and our interlocutor is A.

If rtp packets leave A from port P1, and are destined to B:P2, then the B's media would have to leavr from B:P2 and be destined to A:P1.

thinking about a conferencing application, is it possible to have multiple streams being received in the same local port from different endpoints?

Yes it is, and JMF could actually handle that.

and of course, hearing the audio and sending it correctly?

I am not sure I understand that part.

because testing with the sip communicator code, i've noticed that i cannot establish two successful rtp sessions at the same time, is that my fault or is it how it goes?

I don't know whose fault it is ;), but I don't se why there would be a problem with this and what could it be ...

Cheers
Emil

···

thanks for your help,

borja

On 11/16/05, *Emil Ivov* <emil_ivov@yahoo.com > <mailto:emil_ivov@yahoo.com>> wrote:

    Hi Borja, all,

    This is indeed a bit tricky, and I agree that the way it was so far
    implemented in the SIP Communicator is quite clumsy.

    RFCs, in general, don't say anything about ports where data should be
    sent from. Yet, ideally, when RTP is concerned (especially in a VoIP
    setup) a client would have to transmit from the same port that it
    receives on, so that packets could go successfully through all firewalls
    that the remote party is behind.

    The problem is that when beginning transmission, a client is not certain
    of having already received anything, and it has therefore no clue as to
    where to send from. The way pre1.0 is "dealing" with this was - "ok
    let's just send and receive everything on a preconfigured port so that
    in and out bound packets have a matching port number", which is of
    course quite naive.

    We'd need to find out a better way to do that.

    Any suggestions, anyone?

    Emil

    Borja Gonzalez wrote:
     > Hi,
     >
     > Trying to develop different applciation from sip communicator, I�ve
     > noticed that even if I specify a different port for the local and the
     > remote addresses, when transmitting audio via RTP to the remote
    party,
     > it uses the same port for sending the stream in the local machine
    than
     > the remote one the remote party stablishes via the sdp
    description. This
     > is the scenario:
     >
     > MyPC, for examples, chooses to use port 42050 for RTP , and the
    remote
     > one chooses 32060.
     >
     > When using for receiving, no problem, the connection is as follows:
     >
     > 42050 <------------------ 32060
     >
     > but if i try to send audio, it just won�t do it like this:
     >
     > 42050 -----------------> 32060
     >
     > I found this issue in the past but solved it making the
    connection like
     > this, using the same port as the stated in the sdp description
    from the
     > remote party:
     >
     > 32060 -----------------> 32060 , and that way it worked fine,
    but now i
     > would like to do the connection properly, like the way i described.
     >
     > Is this a known issue with sip-communicator or jmf? I would really
     > appreciate your help.
     >
     > Thanks for your time.
     >
     > borja

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

OK, thanks for your time Emil.

I will check and try to fix it, in 5 days from now, cause now i'm leaving,
i'm pretty sure it's my fault.

bye

borja

···

On 11/16/05, Emil Ivov <emil_ivov@yahoo.com> wrote:

> So, considering that that's how it is, that we have to receive in the
> same port that they send us the rtp streams from,

Not exactly. We have to send from the same port that they send to and to
the same port that they send from. In other words, imagine that we are B
and our interlocutor is A.

If rtp packets leave A from port P1, and are destined to B:P2, then the
B's media would have to leavr from B:P2 and be destined to A:P1.

> thinking about a conferencing application, is it possible to have
> multiple streams being received in the same local port from different
> endpoints?

Yes it is, and JMF could actually handle that.

> and of course, hearing the audio and sending it correctly?

I am not sure I understand that part.

> because testing with the sip communicator code, i've noticed that i
> cannot establish two successful rtp sessions at the same time, is that
> my fault or is it how it goes?

I don't know whose fault it is ;), but I don't se why there would be a
problem with this and what could it be ...

Cheers
Emil

>
> thanks for your help,
>
> borja
>
> On 11/16/05, *Emil Ivov* <emil_ivov@yahoo.com > > <mailto:emil_ivov@yahoo.com>> wrote:
>
> Hi Borja, all,
>
> This is indeed a bit tricky, and I agree that the way it was so far
> implemented in the SIP Communicator is quite clumsy.
>
> RFCs, in general, don't say anything about ports where data should be
> sent from. Yet, ideally, when RTP is concerned (especially in a VoIP
> setup) a client would have to transmit from the same port that it
> receives on, so that packets could go successfully through all firewalls
> that the remote party is behind.
>
> The problem is that when beginning transmission, a client is not certain
> of having already received anything, and it has therefore no clue as to
> where to send from. The way pre1.0 is "dealing" with this was - "ok
> let's just send and receive everything on a preconfigured port so that
> in and out bound packets have a matching port number", which is of
> course quite naive.
>
> We'd need to find out a better way to do that.
>
> Any suggestions, anyone?
>
> Emil
>
> Borja Gonzalez wrote:
> > Hi,
> >
> > Trying to develop different applciation from sip communicator, I´ve
> > noticed that even if I specify a different port for the local and the
> > remote addresses, when transmitting audio via RTP to the remote
> party,
> > it uses the same port for sending the stream in the local machine
> than
> > the remote one the remote party stablishes via the sdp
> description. This
> > is the scenario:
> >
> > MyPC, for examples, chooses to use port 42050 for RTP , and the
> remote
> > one chooses 32060.
> >
> > When using for receiving, no problem, the connection is as follows:
> >
> > 42050 <------------------ 32060
> >
> > but if i try to send audio, it just won´t do it like this:
> >
> > 42050 -----------------> 32060
> >
> > I found this issue in the past but solved it making the
> connection like
> > this, using the same port as the stated in the sdp description
> from the
> > remote party:
> >
> > 32060 -----------------> 32060 , and that way it worked fine,
> but now i
> > would like to do the connection properly, like the way i described.
> >
> > Is this a known issue with sip-communicator or jmf? I would really
> > appreciate your help.
> >
> > Thanks for your time.
> >
> > borja
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net