[SR-Users] Problem initiating a call with dlg_bridge

[Paul Smith]

Hi Daniel,
I’ve just done a few quick tests after “git pull origin” upgrade.  

It works when the 2 snom endpoints are registered over UDP transport with stun enabled.  Which is great thank you very much.

But I have come across a couple of cases that are not working for me yet:

FAIL CASE 1 : It does not send the REFER to the from device when the from device is registered with transport UDP and  with stun disabled.
FAIL CASE 2 : It does not send the REFER to the from device when the from device is registered with transport tcp with stun enabled.  It turns out that the snom is not doing stun when the transport =tcp so this is actually the same case as the one above …. i.e. nat handling and routing.

… not sure yet whether the nat routing failures are is due to my script or the module… I would have thought theREFER should still go to 105 at NATROUTERIP rather than 105 at LANlocalIP?


WORKING CASE : udp transport, stun enabled
--------------------------------------------------------------The message buffer dump at the top of request_route() gives me
 2(3415) INFO: <script>:  --- SCRIPT Got a REFER packet from KAMAILIOSERVERIP to sip:105 at NATROUTERIP:38788;line=1ba8dgba with message buffer:
 REFER sip:105 at NATROUTERIP:38788;line=1ba8dgba SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bK92d2.dc966e61000000000000000000000000.0
To: <sip:105 at KAMAILIOSERVERIP>;tag=uj221nkycd
From: <sip:controller at kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-ca5a
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3d-3421 at KAMAILIOSERVERIP
Route: <sip:KAMAILIOSERVERIP;lr;did=906.c812;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller at kamailio.org
Refer-To: sip:106 at KAMAILIOSERVERIP
Contact: <sip:controller at kamailio.org:5060>



kamctl ul show 105 at KAMAILIOSERVERIP
Contact:: <sip:105 at NATROUTERIP:38788;line=1ba8dgba>;q=1;expires=3592;flags=0x0;cflags=0x40;state=2;socket=<udp:KAMAILIOSERVERIP:5060>;methods=0x17DF;received=<sip:NATROUTERIP:38788>;user_agent=<snom370/8.7.3.19>;+sip.instance=<urn:uuid:b56f3e3c-78ac-4aa2-8073-000413260935>;reg-id=1




FAIL CASE 1 : udp transport + stun disabled
------------------------------------------------------------ The message buffer dump at the top of request_route() gives me

 1(3414) INFO: <script>:  --- SCRIPT Got a REFER packet from KAMAILIOSERVERIP to sip:105 at 192.168.1.15:5060;line=dq8tdtq2 with message buffer:
 REFER sip:105 at 192.168.1.15:5060;line=dq8tdtq2 SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bK03d2.fbd72b40000000000000000000000000.0
To: <sip:105 at KAMAILIOSERVERIP>;tag=z0qd99c588
From: <sip:controller at kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-8a12
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3c-3421 at KAMAILIOSERVERIP
Route: <sip:KAMAILIOSERVERIP;lr;did=016.a3f1;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller at kamailio.org
Refer-To: sip:106 at KAMAILIOSERVERIP
Contact: <sip:controller at kamailio.org:5060>



kamctl ul show 105 at KAMAILIOSERVERIP
Contact:: <sip:105 at 192.168.1.15:5060;line=dq8tdtq2>;q=1;expires=3595;flags=0x0;cflags=0x40;state=2;socket=<udp:KAMAILIOSERVERIP:5060>;methods=0x17DF;received=<sip:NATROUTERIP:38788>;user_agent=<snom370/8.7.3.19>;+sip.instance=<urn:uuid:b56f3e3c-78ac-4aa2-8073-000413260935>;reg-id=1


FAIL CASE 2 : tcp transport + stun enabled.  
---------------------------------------------------------The message buffer dump at the top of request_route() gives me
It looks like the snom ignores stun settings when transport=tcp …. therefore this failure case is actually the same as the one above…. i.e it is a routing / NAT problem when stun is disabled
INFO: <script>:  --- SCRIPT Got a REFER packet from KAMAILIOSERVERIP to sip:105 at 192.168.1.15:1113;transport=tcp;line=vr59tdgv with message buffer:
 REFER sip:105 at 192.168.1.15:1113;transport=tcp;line=vr59tdgv SIP/2.0
Via: SIP/2.0/UDP KAMAILIOSERVERIP;branch=z9hG4bKf2d2.9651ae40000000000000000000000000.0
To: <sip:105 at KAMAILIOSERVERIP>;tag=h233uut5bz
From: <sip:controller at kamailio.org>;tag=48329130e552128b3c54a5eeb8c86eea-4c61
CSeq: 11 REFER
Call-ID: 5abe7c773aaefc3b-3421 at KAMAILIOSERVERIP
Route: <sip:KAMAILIOSERVERIP;r2=on;lr;did=f06.06e;nat=yes>, <sip:KAMAILIOSERVERIP;transport=tcp;r2=on;lr;did=f06.06e;nat=yes>
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (4.2.0 (x86_64/linux))
Referred-By: sip:controller at kamailio.org
Refer-To: sip:106 at KAMAILIOSERVERIP
Contact: <sip:controller at kamailio.org:5060>


kamctl ul show 105 at KAMAILIOSERVERIP
Contact:: <sip:105 at 192.168.1.15:1113;transport=tcp;line=vr59tdgv>;q=1;expires=3587;flags=0x0;cflags=0x40;state=2;socket=<tcp:KAMAILIOSERVERIP:5060>;methods=0x17DF;received=<sip:NATROUTERIP:34841;transport=TCP>;user_agent=<snom370/8.7.3.19>;+sip.instance=<urn:uuid:b56f3e3c-78ac-4aa2-8073-000413260935>;reg-id=1


On 29 Oct 2014, at 11:11, Daniel-Constantin Mierla <miconda at gmail.com> wrote:

> Hello,
> 
> should be fixed in 4.2 -- the issue was introduced when changed the build of refer to contain a contact header, as it was reported some UA don't like it without the header.
> 
> Let me know if all works ok now.
> 
> Cheers,
> Daniel
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141029/2db93b63/attachment.html>