OverSIP upstream BYE issues

[Vladut Paiu]

Hello,

I have a setup where I'm using SIPML5 as the websocket client, and OverSIP as a WS to SIP gateway.
Call establishment is working ok, and also call termination from the caller side is all good.

Still, when the callee hangs up the call, OverSIP is rejecting the BYE, and the caller is left hanging in the call.
For the Callee BYE, OverSIP replies with a 478 Unsupported Transport, and in the log file I can see the following :

syslog.5:3268:Apr  3 16:47:04 siphub oversip[13840]:  DEBUG: <SipEvents> [user] proxying in-dialog BYE
syslog.5:3269:Apr  3 16:47:04 siphub oversip[13840]:  DEBUG: <Proxy proxy_in_dialog 3133.fa229da2.0> unsupported transport
syslog.5:3270:Apr  3 16:47:04 siphub oversip[13840]:  DEBUG: <SIP Request 3133.fa229da2.0> replying 478 "Unsupported Transport"

Find attached the two traces, one for the BYE from the caller, which is completed succesfully, and the other with the BYE from the callee, which fails to be routed.
Any help would be greatly appreciated.

Best Regards,
Vlad

[Iñaki Baz Castillo]

As you can see, the bottom Route header in the BYE sent from the peer
(in oversip_callee_bye.txt) does NOT provide a username in the URI.
That's a bug in such a peer since OverSIP adds a Record-Route with a
username in the URI as RFC 5626 (Outbound) states. Without the URI
username OverSIP has no way to know which WS connection the request
belongs to so tries to route the request by following RFC 3263 rules,
and that's not posible in the case of a client behind NAT.

Could you please provide an entire call flow for the callee_bye
scenario? For sure OverSIP adds a Record-Route with username in the
;transport=ws URI but the other peer does not respect it. That's the
problem since RFC 3261 mandates that any component (username,
parameters) in the Record-Route must be mirrored in the Route set once
the dialog is established.

2013/4/8 Vladut Paiu <vladu...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "OverSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to oversip+u...@googlegroups.com.
> To post to this group, send an email to ove...@googlegroups.com.
> Visit this group at http://groups.google.com/group/oversip?hl=en-GB.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Iñaki Baz Castillo
<i...@aliax.net>

[Vladut Paiu]

Hello,

Thanks for your reply.

The Topology is :

SIPML5 client -> OverSIP -> OpenSIPS -> another SIPML5 client

Please find attached the SIP trace. When the INVITE comes into OpenSIPS from OverSIP, there is no username in the Route header.

Currently I am using mostly the default OverSIP config file.

Best Regards,

Vlad

[Iñaki Baz Castillo]

ok, I don't see in the INVITE that your UA (the caller) indicates
support of Outbound (RFC 5626) at all, so OverSIP is not applying
Outbound and thus it does not add a username to the WS Record-Route
URI. I will change it in OverSIP 1.4 to always assume Outbound in
requests coming from WS clients:

https://github.com/versatica/OverSIP/issues/43

Until that, you can force Outbound for the INVITE from WS clients
using the Request.fix_nat method. Search "fix_nat" in the API:

http://www.oversip.net/documentation/1.3.x/api/sip/core/


For example you can do in your oversip.rb:


if request.websocket?
request.fix_nat
end

and you are done.




2013/4/9 Vladut Paiu <vladu...@gmail.com>:

[Iñaki Baz Castillo]

2013/4/9 Iñaki Baz Castillo <i...@aliax.net>:

> For example you can do in your oversip.rb:

Sorry, I mean "in your server.rb".


>
> if request.websocket?
> request.fix_nat
> end

[Vladut Paiu]

Hi,

Thanks, understood the issue now.

Still, looking in the server.rb I see, in the default cfg file :

  # Assume all the traffic is from clients and help them with NAT issues

  # by forcing rport usage and Outbound mechanism.

  request.fix_nat

So the fix_nat was already called. 

Looking at the docs, I see that all the outbound requirements are fullfilled :

• It is an initial SIP request.
• It has a single Via value (so the request has not been previously forwarded by another SIP proxy).
• The SIP method is INVITE, REGISTER, SUBSCRIBE or REFER.

Any ideas on why it would be failing ?

Best Regards,

Vlad

[Iñaki Baz Castillo]

2013/4/9 Vladut Paiu <vladu...@gmail.com>:

> Hi,
>
> Thanks, understood the issue now.
> Still, looking in the server.rb I see, in the default cfg file :
>
> # Assume all the traffic is from clients and help them with NAT issues
> # by forcing rport usage and Outbound mechanism.
> request.fix_nat
>
> So the fix_nat was already called.
>
> Looking at the docs, I see that all the outbound requirements are fullfilled
> :
>
> It is an initial SIP request.
> It has a single Via value (so the request has not been previously forwarded
> by another SIP proxy).
> The SIP method is INVITE, REGISTER, SUBSCRIBE or REFER.
>
>
> Any ideas on why it would be failing ?

I've tested right now SIPml5 and OverSIP adds the username to the WS
Record-Route URI. No idea what is happening in your scenario, never
seen such an issue.

Could you please ensure that request.fix_nat is really being called?
(i.e. by adding a log line in the line after request.fix_nat and
checking syslog?).

[Vladut Paiu]

Hello,

I have added extra logging for the INVITE processing, before and after calling request.fix_nat. I also notice some errors messages, but the INVITE message is succesfuly relayed out.
Here's the log :


Apr 10 18:22:14 siphub oversip[31931]:   INFO: <SipEvents> [user] INVITE from sip:vlad.paiu@MY_DOAMIN (UA: WebClientJmecher) to sip:li...@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=ws;ov-ob=17d1809387 via UDP SIP_IP : 5060 routes =  ; callid = 1724058f-60e4-dc99-1143-72aa157ba47d
Apr 10 18:22:14 siphub oversip[31931]:   INFO: <SipEvents> [user] Calling request.fix_nat for invite with callid = 1724058f-60e4-dc99-1143-72aa157ba47d
Apr 10 18:22:14 siphub oversip[31931]:   INFO: <SipEvents> [user] After calling request.fix_nat : INVITE from sip:vlad.paiu@MY_DOMAIN (UA: WebClientJmecher) to sip:li...@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=ws;ov-ob=17d1809387 via UDP SIP_IP : 5060 routes =  ; callid = 1724058f-60e4-dc99-1143-72aa157ba47d
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <OutboundMangling module> incoming Outbound flow token extracted from ;ov-ob param in RURI for SIP Request 0a7c.57cbc835.1
Apr 10 18:22:14 siphub oversip[31931]:   INFO: <SipEvents> [user] routing initial request to an Outbound client
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <SIP Request 0a7c.57cbc835.1> replying 100 "Trying"
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <Proxy proxy_to_users 0a7c.57cbc835.1> flow failed
Apr 10 18:22:14 siphub oversip[31931]: NOTICE: <SipEvents> [user] incoming Outbound on_error: 430 'Flow Failed'
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <SIP Request 0a7c.57cbc835.1> replying 430 "Flow Failed"
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <IST 0a7c.57cbc835.1> ACK received during completed state, now confirmed
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <WsFraming> received text frame: FIN=true, RSV1-3=false/false/false, payload_length=995
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <WsSipApp> received WS message: type=text, length=995
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <WsFraming> received text frame: FIN=true, RSV1-3=false/false/false, payload_length=1124
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <WsSipApp> received WS message: type=text, length=1124
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <Proxy proxy_to_users 0a7c.57cbc835.0> received response 180
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <SIP Request 0a7c.57cbc835.0> forwarding response 180 "Ringing"
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <Proxy proxy_out T2oi7xlavIiqWoaZP92J2OzeCCQlKqAE> received response 180
Apr 10 18:22:14 siphub oversip[31931]:   INFO: <SipEvents> [user] on_provisional_response: 180 'Ringing'
Apr 10 18:22:14 siphub oversip[31931]:  DEBUG: <SIP Request T2oi7xlavIiqWoaZP92J2OzeCCQlKqAE> forwarding response 180 "Ringing"



Best Regards,
Vlad

[Iñaki Baz Castillo]

Which OverSIP version?

2013/4/10 Vladut Paiu <vladu...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "OverSIP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to oversip+u...@googlegroups.com.
> To post to this group, send an email to ove...@googlegroups.com.
> Visit this group at http://groups.google.com/group/oversip?hl=en-GB.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Vladut Paiu]

Hello,

Using OverSIP 1.3.7


Best Regards,
Vlad

[Iñaki Baz Castillo]

Could you please also log the entire request just BEFORE calling to
proxy.route() ?

log_info request.to_s

[Vladut Paiu]

Hi,

Here is the output ( SDP body stripped ), just before calling proxy.route for the initial INVITE :

INVITE sip:liviu@SIP_DOMAIN SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKnHrNqT1xsQoZTpGiy6ZS0AEx0UKLTKyR;rport
From: "vladut"<sip:vlad.paiu@SIP_DOMAIN>;tag=EfXunS9IHscmvhauKKm0
To: <sip:liviu@SIP_DOMAIN>
Contact: "vladut"<sips:vlad...@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=wss>;+g.oma.sip-im;+sip.ice;language="en,fr"
Call-ID: 9d0e4b37-f192-eb5f-e0e5-d0d3584f6050
CSeq: 18115 INVITE
Content-Type: application/sdp
Content-Length: 3886
Max-Forwards: 70

I see no route headers at all there, but the outgoing INVITE does have two routes headers..

Best Regards,
Vlad

[Iñaki Baz Castillo]

Sorry, my fault, the console log should be placed *after* the
proxy.route() call. So sorry... could you repeat it please?

2013/4/11 Vladut Paiu <vladu...@gmail.com>:

[Vladut Paiu]

Hi,

No worries. Here's the new output :

INVITE sip:vlad.paiu@SIP_DOMAIN SIP/2.0
Record-Route: <sip:OVERSIP_IP:10080;transport=ws;lr;ovid=d65bb4f6>
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKt7mwHEGqWz59aO0TM2Vf1hoveo8QFCIi;rport
From: "Bogdan"<sip:bogdan@SIP_DOMAIN>;tag=bU3NSV1osdJvZzT3knbK
To: <sip:vlad.paiu@SIP_DOMAIN>
Contact: "Bogdan"<sip:bog...@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
Call-ID: 923193e2-c2fa-3684-ca08-b1389c8da7f1
CSeq: 60466 INVITE
Content-Type: application/sdp
Content-Length: 3145
Max-Forwards: 10

Regards,
Vlad

joi, 11 aprilie 2013, 14:27:17 UTC+3, Iñaki Baz Castillo a scris:

Sorry, my fault, the console log should be placed *after* the
proxy.route() call. So sorry... could you repeat it please?

2013/4/11 Vladut Paiu <vladu...@gmail.com>:
> Hi,
>
> Here is the output ( SDP body stripped ), just before calling proxy.route
> for the initial INVITE :
>
> INVITE sip:liviu@SIP_DOMAIN SIP/2.0
> Via: SIP/2.0/WSS
> df7jal23ls0d.invalid;branch=z9hG4bKnHrNqT1xsQoZTpGiy6ZS0AEx0UKLTKyR;rport
> From: "vladut"<sip:vlad.paiu@SIP_DOMAIN>;tag=EfXunS9IHscmvhauKKm0
> To: <sip:liviu@SIP_DOMAIN>
> Contact:

> "vladut"<sips:vlad.paiu@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=wss>;+g.oma.sip-im;+sip.ice;language="en,fr"

[Iñaki Baz Castillo]

Honestly this is very strange and I cannot reproduce the problem. I'd
strongly like to help with it. Could I try your scenario? is it
possible? If so we can have private mails.

>> > "vladut"<sips:vlad...@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=wss>;+g.oma.sip-im;+sip.ice;language="en,fr"

[Sunil Singh]

Dear Inaki/vlad,

Please help me configure oversip to use below scenario.

SIPML5 client -> OverSIP -> sip server.

I have installed over sip (12.10) on ubuntu linux ( 3.13.0-24-generic). I can see over sip is running on 10.48.71.71 properly.

root@dvas-temp:/etc/oversip# ps -ef | grep -i oversip

oversip   1885     1  0 Jul28 ?        00:00:07 oversip

oversip   1889  1885  0 Jul28 ?        00:00:01 oversip_syslogger

oversip   1894     1  0 Jul28 ?        00:00:00 ./oversip_stud -u oversip -g oversip -f 10.48.71.71,5061 -b 127.0.0.1,5062 -n 2 -s --daemon --write-proxy /tmp/oversip_full_cert_20140728-1879-j9lgxl

oversip   1895  1894  0 Jul28 ?        00:00:00 ./oversip_stud -u oversip -g oversip -f 10.48.71.71,5061 -b 127.0.0.1,5062 -n 2 -s --daemon --write-proxy /tmp/oversip_full_cert_20140728-1879-j9lgxl

oversip   1896  1894  0 Jul28 ?        00:00:00 ./oversip_stud -u oversip -g oversip -f 10.48.71.71,5061 -b 127.0.0.1,5062 -n 2 -s --daemon --write-proxy /tmp/oversip_full_cert_20140728-1879-j9lgxl

oversip   1899     1  0 Jul28 ?        00:00:00 ./oversip_stud -u oversip -g oversip --ssl -f 10.48.71.71,10443 -b 127.0.0.1,10444 -n 2 -s --daemon --write-proxy /tmp/oversip_full_cert_20140728-1879-j9lgxl

oversip   1900  1899  0 Jul28 ?        00:00:00 ./oversip_stud -u oversip -g oversip --ssl -f 10.48.71.71,10443 -b 127.0.0.1,10444 -n 2 -s --daemon --write-proxy /tmp/oversip_full_cert_20140728-1879-j9lgxl

oversip   1901  1899  0 Jul28 ?        00:00:00 ./oversip_stud -u oversip -g oversip --ssl -f 10.48.71.71,10443 -b 127.0.0.1,10444 -n 2 -s --daemon --write-proxy /tmp/oversip_full_cert_20140728-1879-j9lgxl

root      3115  3079  0 10:19 pts/14   00:00:00 grep --color=auto -i oversip

I have downloaded sipml5 client. Now to proceed further mean I am trying to login (register) a user from sipml5 by giving sip:b...@10.48.71.71:5060 as public identity and realm as 10.48.71.71:5060.. but it did not work.

friends please help me.

Thanks in advance

Best Regards,

Sunil

On Friday, April 12, 2013 7:16:28 PM UTC+5:30, Iñaki Baz Castillo wrote:

Honestly this is very strange and I cannot reproduce the problem. I'd
strongly like to help with it. Could I try your scenario? is it
possible? If so we can have private mails.

2013/4/11 Vladut Paiu <vladu...@gmail.com>:
> Hi,
>
> No worries. Here's the new output :
>
> INVITE sip:vlad.paiu@SIP_DOMAIN SIP/2.0
> Record-Route: <sip:OVERSIP_IP:10080;transport=ws;lr;ovid=d65bb4f6>
> Via: SIP/2.0/WS
> df7jal23ls0d.invalid;branch=z9hG4bKt7mwHEGqWz59aO0TM2Vf1hoveo8QFCIi;rport
> From: "Bogdan"<sip:bogdan@SIP_DOMAIN>;tag=bU3NSV1osdJvZzT3knbK
> To: <sip:vlad.paiu@SIP_DOMAIN>
> Contact:

> "Bogdan"<sip:bogdan@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"

> Call-ID: 923193e2-c2fa-3684-ca08-b1389c8da7f1
> CSeq: 60466 INVITE
> Content-Type: application/sdp
> Content-Length: 3145
> Max-Forwards: 10
>
> Regards,
> Vlad
>
> joi, 11 aprilie 2013, 14:27:17 UTC+3, Iñaki Baz Castillo a scris:
>>
>> Sorry, my fault, the console log should be placed *after* the
>> proxy.route() call. So sorry... could you repeat it please?
>>
>> 2013/4/11 Vladut Paiu <vladu...@gmail.com>:
>> > Hi,
>> >
>> > Here is the output ( SDP body stripped ), just before calling
>> > proxy.route
>> > for the initial INVITE :
>> >
>> > INVITE sip:liviu@SIP_DOMAIN SIP/2.0
>> > Via: SIP/2.0/WSS
>> >
>> > df7jal23ls0d.invalid;branch=z9hG4bKnHrNqT1xsQoZTpGiy6ZS0AEx0UKLTKyR;rport
>> > From: "vladut"<sip:vlad.paiu@SIP_DOMAIN>;tag=EfXunS9IHscmvhauKKm0
>> > To: <sip:liviu@SIP_DOMAIN>
>> > Contact:
>> >

>> > "vladut"<sips:vlad.paiu@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=wss>;+g.oma.sip-im;+sip.ice;language="en,fr"

[Miguel Oyarzo]

Create a new thread.