[sip-comm-dev] Possible Issue with SDP & RTP


#1

Hey Javier,

I'll be looking into it now and I'll let you know as soon as there's a definite answer.

Best regards,
Lubo

···

On 10/3/2008 4:28 PM, Javier Mendiara Ca�ardo wrote:

Hi all,

I think I've found an issue with RTP retransmission.
If two SDP descriptions are sent in INVITES in the same SIP Dialog,
SipComm sends RTP to the destination specified in the first INVITE, and
I think it should be sent to the specified in the last INVITE

Attached there are 3 files, the sipcomm log (FINE graining), Wireshark
Dump and a JPG showing where SIP server sends the second INVITE with the
correct SDP and where is sending SIPComm the RTP audio.

As you can see, the other softphone is sending RTP directly to SipComm,
but SipComm is sending audio via SIP Server.

The scenario is as follows:
A SipCommunicator (SVN 4548) located at 192.168.1.135, with SIP ID 6003,
running under WinXP Pro SP3, java1.6, from Netbeans ANT run
One SIP Gateway (GrandStream HT503) located at 192.168.1.102, with SIP
ID 6000
Asterisk SIP server (v1.4.18.1) located at 192.168.1.101, forcing G711U
(ULAW) codec
WireShark (tcpdump) listening in 192.168.1.135 (where sipcomm is located)

In the wireshark dump there is also debug info from the SIP Gateway
(sip:6000) sent using SysLog events (WireShark filter: syslog)
In "Log Sipcommunicator.log" file, line 914, you can see the second INVITE

This behaviour is a pity, because if the SIPComm and GW are in the same
LAN and the asterisk is outside, the Sipcommunicator voice will travel
too long to reach the destination, while GW to SIP voice will travel
using the LAN.

One thing more, I've forced in Asterisk to use G711U, so I think that
Asterisk media server conversion between audio formats is not causing
this. Also, both SDP are identical.

What do you think? Is it possible to solve?

PS: I've tried with other softphones, and it seems that this issue is
correctly managed.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: 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


#2

Lubomir Marinov wrote:

I found the exact same problem connecting with an Asterisk server. I modified the code to answer the second invite and not the first. Took me forever to find it and was wondering why no one else seemed to have this problem.

BTW, if you are calling out, the problem doesn't arise.

Kim

···

Hey Javier,

I'll be looking into it now and I'll let you know as soon as there's a definite answer.

Best regards,
Lubo

On 10/3/2008 4:28 PM, Javier Mendiara Ca�ardo wrote:

Hi all,

I think I've found an issue with RTP retransmission.
If two SDP descriptions are sent in INVITES in the same SIP Dialog,
SipComm sends RTP to the destination specified in the first INVITE, and
I think it should be sent to the specified in the last INVITE

Attached there are 3 files, the sipcomm log (FINE graining), Wireshark
Dump and a JPG showing where SIP server sends the second INVITE with the
correct SDP and where is sending SIPComm the RTP audio.

As you can see, the other softphone is sending RTP directly to SipComm,
but SipComm is sending audio via SIP Server.

The scenario is as follows:
A SipCommunicator (SVN 4548) located at 192.168.1.135, with SIP ID 6003,
running under WinXP Pro SP3, java1.6, from Netbeans ANT run
One SIP Gateway (GrandStream HT503) located at 192.168.1.102, with SIP
ID 6000
Asterisk SIP server (v1.4.18.1) located at 192.168.1.101, forcing G711U
(ULAW) codec
WireShark (tcpdump) listening in 192.168.1.135 (where sipcomm is located)

In the wireshark dump there is also debug info from the SIP Gateway
(sip:6000) sent using SysLog events (WireShark filter: syslog)
In "Log Sipcommunicator.log" file, line 914, you can see the second INVITE

This behaviour is a pity, because if the SIPComm and GW are in the same
LAN and the asterisk is outside, the Sipcommunicator voice will travel
too long to reach the destination, while GW to SIP voice will travel
using the LAN.

One thing more, I've forced in Asterisk to use G711U, so I think that
Asterisk media server conversion between audio formats is not causing
this. Also, both SDP are identical.

What do you think? Is it possible to solve?

PS: I've tried with other softphones, and it seems that this issue is
correctly managed.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: 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

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


#3

As far as I know Sip Communicator does not handle reInvites (What you
described is reInvite Functionality).So simply put yes the application
behaviour should be different - but it is not a bug but application
shortenning.

What is more if you have SDP in ACK it is allso ignored from Media point of
view.

Lubomir Marinov wrote:

···

I found the exact same problem connecting with an Asterisk server. I
modified the code to answer the second invite and not the first. Took me
forever to find it and was wondering why no one else seemed to have this
problem.

BTW, if you are calling out, the problem doesn't arise.

Kim

Hey Javier,

I'll be looking into it now and I'll let you know as soon as there's a
definite answer.

Best regards,
Lubo

On 10/3/2008 4:28 PM, Javier Mendiara Cañardo wrote:

Hi all,

I think I've found an issue with RTP retransmission.
If two SDP descriptions are sent in INVITES in the same SIP Dialog,
SipComm sends RTP to the destination specified in the first INVITE, and
I think it should be sent to the specified in the last INVITE

Attached there are 3 files, the sipcomm log (FINE graining), Wireshark
Dump and a JPG showing where SIP server sends the second INVITE with the
correct SDP and where is sending SIPComm the RTP audio.

As you can see, the other softphone is sending RTP directly to SipComm,
but SipComm is sending audio via SIP Server.

The scenario is as follows:
A SipCommunicator (SVN 4548) located at 192.168.1.135, with SIP ID 6003,
running under WinXP Pro SP3, java1.6, from Netbeans ANT run
One SIP Gateway (GrandStream HT503) located at 192.168.1.102, with SIP
ID 6000
Asterisk SIP server (v1.4.18.1) located at 192.168.1.101, forcing G711U
(ULAW) codec
WireShark (tcpdump) listening in 192.168.1.135 (where sipcomm is
located)

In the wireshark dump there is also debug info from the SIP Gateway
(sip:6000) sent using SysLog events (WireShark filter: syslog)
In "Log Sipcommunicator.log" file, line 914, you can see the second
INVITE

This behaviour is a pity, because if the SIPComm and GW are in the same
LAN and the asterisk is outside, the Sipcommunicator voice will travel
too long to reach the destination, while GW to SIP voice will travel
using the LAN.

One thing more, I've forced in Asterisk to use G711U, so I think that
Asterisk media server conversion between audio formats is not causing
this. Also, both SDP are identical.

What do you think? Is it possible to solve?

PS: I've tried with other softphones, and it seems that this issue is
correctly managed.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: 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

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


#4

Folks, complete support for reINVITEs is coming soon so stay tuned.

Emil

P.S. We actually do suppport reINVITEs even now since this is how the
"call hold" feature works. It's just that we don't seem to be handling
them in all possible cases. Again, coming soon.

Przemysław Dudek написа:

···

As far as I know Sip Communicator does not handle reInvites (What you
described is reInvite Functionality).
So simply put yes the application behaviour should be different - but it
is not a bug but application shortenning.

What is more if you have SDP in ACK it is allso ignored from Media point
of view.

    Lubomir Marinov wrote:

    I found the exact same problem connecting with an Asterisk server. I
    modified the code to answer the second invite and not the first.
    Took me forever to find it and was wondering why no one else seemed
    to have this problem.

    BTW, if you are calling out, the problem doesn't arise.

    Kim

        Hey Javier,

        I'll be looking into it now and I'll let you know as soon as
        there's a definite answer.

        Best regards,
        Lubo

        On 10/3/2008 4:28 PM, Javier Mendiara Cañardo wrote:

            Hi all,

            I think I've found an issue with RTP retransmission.
            If two SDP descriptions are sent in INVITES in the same SIP
            Dialog,
            SipComm sends RTP to the destination specified in the first
            INVITE, and
            I think it should be sent to the specified in the last INVITE

            Attached there are 3 files, the sipcomm log (FINE graining),
            Wireshark
            Dump and a JPG showing where SIP server sends the second
            INVITE with the
            correct SDP and where is sending SIPComm the RTP audio.

            As you can see, the other softphone is sending RTP directly
            to SipComm,
            but SipComm is sending audio via SIP Server.

            The scenario is as follows:
            A SipCommunicator (SVN 4548) located at 192.168.1.135
            <http://192.168.1.135>, with SIP ID 6003,
            running under WinXP Pro SP3, java1.6, from Netbeans ANT run
            One SIP Gateway (GrandStream HT503) located at 192.168.1.102
            <http://192.168.1.102>, with SIP
            ID 6000
            Asterisk SIP server (v1.4.18.1) located at 192.168.1.101
            <http://192.168.1.101>, forcing G711U
            (ULAW) codec
            WireShark (tcpdump) listening in 192.168.1.135
            <http://192.168.1.135> (where sipcomm is located)

            In the wireshark dump there is also debug info from the SIP
            Gateway
            (sip:6000) sent using SysLog events (WireShark filter: syslog)
            In "Log Sipcommunicator.log" file, line 914, you can see the
            second INVITE

            This behaviour is a pity, because if the SIPComm and GW are
            in the same
            LAN and the asterisk is outside, the Sipcommunicator voice
            will travel
            too long to reach the destination, while GW to SIP voice
            will travel
            using the LAN.

            One thing more, I've forced in Asterisk to use G711U, so I
            think that
            Asterisk media server conversion between audio formats is
            not causing
            this. Also, both SDP are identical.

            What do you think? Is it possible to solve?

            PS: I've tried with other softphones, and it seems that this
            issue is
            correctly managed.

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

            ---------------------------------------------------------------------
            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
        <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
    <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