Janus SIP plugin use UDP transport instead of TCP

[Дмитрий Поволоцкий]

Hello. 

My SIP call lasts 1800 seconds (30 mins). In SIP-operator support sad, that I have to use UDP transport unstead of TCP. 

Is it possibe?

Thank you.

[Lorenzo Miniero]

I think that's what we're already doing.

L.

[Дмитрий Поволоцкий]

In LOG I see

.INVITE sip:8916*****6...@voip.sipuni.com SIP/2.0
.Via: SIP/2.0/TCP 83.166.240.72:49546;received=83.166.240.72;rport=42273;branch=z9hG4bK89v5XrNNBK2pj

Is it possible make INVITE VIA UDP?

Thank you.

пятница, 15 сентября 2017 г., 19:53:01 UTC+3 пользователь Lorenzo Miniero написал:

[Lorenzo Miniero]

AFAIK it should do UDP by default, maybe something in your REGISTER exchange makes it think it needs to use TCP, or UDP fails. Check the SIP messages the plugin exchange with the SIP infrastructure since the beginning to see if you can spot why.

L.

[nasu...@gmail.com]

Hello there,

I'm also curious about this issue. Does anybody know about this? 

REGISTER can be sent over UDP. But I couldn't make it to send INVITE over UDP. INVITE is always sent over only TCP.

Thanks in advance.

Sunhee

2017년 9월 18일 월요일 오후 8시 30분 38초 UTC+9, Lorenzo Miniero 님의 말:

AFAIK it should do UDP by default, maybe something in your REGISTER exchange makes it think it needs to use TCP, or UDP fails. Check the SIP messages the plugin exchange with the SIP infrastructure since the beginning to see if you can spot why.

L.

Il giorno lunedì 18 settembre 2017 11:50:36 UTC+2, Дмитрий Поволоцкий ha scritto:

In LOG I see

.INVITE sip:8916*...@voip.sipuni.com SIP/2.0

.Via: SIP/2.0/TCP 83.166.240.72:49546;received=83.166.240.72;rport=42273;branch=z9hG4bK89v5XrNNBK2pj

Is it possible make INVITE VIA UDP?

[Lorenzo Miniero]

Again, check the REGISTER response, it may fall to TCP for INVITEs because of something it gets back there.

L.

[Mirko Brankovic]

As far as I can see, 200 OK message response is limiting session dialog to 30 min :

Session-Expires: 1800;refresher=uas

 Also I see that some OPTION messages back goes with

Max-Forwards:0

 So could be that you have some loop for option messages and UAS is not refresing the session which then gets destroyed.

On Thu, Sep 21, 2017 at 8:40 AM, <nasu...@gmail.com> wrote:

Hi,

I don't know what I have to check. I attached a pcap file. Could you check the packet and tell me what is wrong?

2017년 9월 21일 목요일 오후 2시 59분 8초 UTC+9, Lorenzo Miniero 님의 말:

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[nasu...@gmail.com]

Hi,

My question is not a call session limitation but a transport protocol.

If you see the attached pcap log, you could see REGISTER was sent over UDP and INVITE was sent over TCP.

I want to know why INVITE is sent over TCP. And I want to know how I can send INVITE over UDP.

2017년 9월 21일 목요일 오후 4시 14분 32초 UTC+9, Mirko Brankovic 님의 말:

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Mirko Brankovic]

oh indeed ..

not sure, I thought it might be because of mtu and size of packets, but I see at some point one OPTION was sent over UDP and then agin switched back to TCP.

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[nasu...@gmail.com]

Hi,

I'm sorry..I can't understand what you are saying exactly. Could you explain it more easily?

Do you think that OPTION is the problem?

OPTION is automatically sent from Janus. and I don't know why max-forward value is 0.

2017년 9월 21일 목요일 오후 6시 39분 4초 UTC+9, Mirko Brankovic 님의 말: