D1. Brekeke Product Name and version: Brekeke SIP Server 2.4.7
2. Java version: 1.6_023
3. OS type and the version: Windows XP
4. UA (phone), gateway or other hardware/software involved: Bria iPhone Client 1.2.6
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html : 1
6. Your problem: I have two Bria iPhone SIP clients. Both register and work fine using SIP UDP signaling. Both also register correctly when I set to TCP, and can make outbound calls, but they will not receive inbound calls. I ran a wireshark trace and it looks like Brekeke is forwarding an invite to the client, but never receives a response and ultimately the server times out.
Switching from SIP UDP to TCP Signaling with Bria iPhones
Moderator: Brekeke Support Team
Reply
Yes, Brekeke does forward the invite to Bria over TCP. See below (10.0.0.3 is Brekeke address, sip:1001 - 10.0.0.4 trying to dial to sip:1002 - 10.0.0.9). The destination SIP port for sip:1002 is 5060, sent out over TCP port 49295
The invite gets sent but no reply is received from the client so eventually the server times out.
From-uri sip:1001@10.0.0.3
From-ip 10.0.0.4:49199 (TCP)
From-if 10.0.0.3:5060
To-uri sip:1002@10.0.0.3:5060
To-ip 10.0.0.9:49295 (TCP)
To-if 10.0.0.3:1306
Call-ID 8zxNd1km5TjfvUyDws8RVjmTOkntM-ho
rule registered=sip:1002(sip:1002@10.0.0.9:49295)
plug-in InviteSession
The invite gets sent but no reply is received from the client so eventually the server times out.
From-uri sip:1001@10.0.0.3
From-ip 10.0.0.4:49199 (TCP)
From-if 10.0.0.3:5060
To-uri sip:1002@10.0.0.3:5060
To-ip 10.0.0.9:49295 (TCP)
To-if 10.0.0.3:1306
Call-ID 8zxNd1km5TjfvUyDws8RVjmTOkntM-ho
rule registered=sip:1002(sip:1002@10.0.0.9:49295)
plug-in InviteSession
1002 registration
See below:
Expires : 900
Priority : 1000
User Agent : Bria iPhone 1.2.7
Requester : 10.0.0.9:49164
Time Update : Thu Jan 27 12:48:58 PST 2011
The port doesn't exactly match what I had earlier because I re-registered the client.
Thanks
Expires : 900
Priority : 1000
User Agent : Bria iPhone 1.2.7
Requester : 10.0.0.9:49164
Time Update : Thu Jan 27 12:48:58 PST 2011
The port doesn't exactly match what I had earlier because I re-registered the client.
Thanks
Dialplan
Hi,
I entered your dial plan and applied the rules, then restarted the server and re-registered the clients. Again, it worked fine using UDP. With TCP, I have the same problem, outbound is OK, but inbound invites are never answered by the client.
I am new to the dial plan syntax. The matching pattern rule looks straightforward, but I am not clear what the deploy pattern rule is trying to do? Just trying to learn and I really appreciate your help.
Regards.
I entered your dial plan and applied the rules, then restarted the server and re-registered the clients. Again, it worked fine using UDP. With TCP, I have the same problem, outbound is OK, but inbound invites are never answered by the client.
I am new to the dial plan syntax. The matching pattern rule looks straightforward, but I am not clear what the deploy pattern rule is trying to do? Just trying to learn and I really appreciate your help.
Regards.
Re: Dialplan
I looked at the traces for UDP vs. TCP. When the clients registered using UDP, the port assignments in the Contact URI exactly match the port assignment shown in the {detail} section under View Clients within the admin portal.
However, when the clients register using TCP, the port assignment in the Contact URI does not match the port assignment shown the [detail] section. When Bekeke forwards the incoming call invite to the client, it uses the port assignment recorded in the Contact URI.
Below is an excerpt from the registration stream of the Bria client (sip:1002@10.0.0.9) using TCP. The Via header shows that the packet came from port 49159, but the Contact URI shows 49158.
When I look at a registration trace using UDP, the ports shown in the Via header and Contact URI match exactly.
Is there a way I can modify the dialplan so the registration records the port number from the Via Header?
Regards,
REGISTER sip:10.0.0.3 SIP/2.0
Via: SIP/2.0/TCP 10.0.0.9:49159;rport;branch=z9hG4bKPjK5ybei15TqLHsnHdnMWbvvFL6dT46tJ-
Max-Forwards: 70
From: "Iphone4" <sip:1002@10.0.0.3>;tag=H1vbNWTIwFFwhNprtAFByBVQ.4Q8.ETs
To: "Iphone4" <sip:1002@10.0.0.3>
Call-ID: GbTIPeA-vK66ne-6dzh-rIZGLSTT3XwW
CSeq: 59603 REGISTER
User-Agent: Bria iPhone 1.2.7
Contact: "Iphone4" <sip:1002@10.0.0.9:49158;transport=TCP>
Expires: 900
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
However, when the clients register using TCP, the port assignment in the Contact URI does not match the port assignment shown the [detail] section. When Bekeke forwards the incoming call invite to the client, it uses the port assignment recorded in the Contact URI.
Below is an excerpt from the registration stream of the Bria client (sip:1002@10.0.0.9) using TCP. The Via header shows that the packet came from port 49159, but the Contact URI shows 49158.
When I look at a registration trace using UDP, the ports shown in the Via header and Contact URI match exactly.
Is there a way I can modify the dialplan so the registration records the port number from the Via Header?
Regards,
REGISTER sip:10.0.0.3 SIP/2.0
Via: SIP/2.0/TCP 10.0.0.9:49159;rport;branch=z9hG4bKPjK5ybei15TqLHsnHdnMWbvvFL6dT46tJ-
Max-Forwards: 70
From: "Iphone4" <sip:1002@10.0.0.3>;tag=H1vbNWTIwFFwhNprtAFByBVQ.4Q8.ETs
To: "Iphone4" <sip:1002@10.0.0.3>
Call-ID: GbTIPeA-vK66ne-6dzh-rIZGLSTT3XwW
CSeq: 59603 REGISTER
User-Agent: Bria iPhone 1.2.7
Contact: "Iphone4" <sip:1002@10.0.0.9:49158;transport=TCP>
Expires: 900
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
jsu9 wrote:Hi,
I entered your dial plan and applied the rules, then restarted the server and re-registered the clients. Again, it worked fine using UDP. With TCP, I have the same problem, outbound is OK, but inbound invites are never answered by the client.
I am new to the dial plan syntax. The matching pattern rule looks straightforward, but I am not clear what the deploy pattern rule is trying to do? Just trying to learn and I really appreciate your help.
Regards.
One of following rules will avoid the problem..
Try this rule first.
-------------------------------------------------
[Matching Patterns]
$request = ^REGISTER
$transport = TCP
[Deploy Patterns]
®ister.contact.remote = true
$continue = true
-------------------------------------------------
If it doesn't work, remove it and try the next rule.
-------------------------------------------------
[Matching Patterns]
$request = ^REGISTER
Via = TCP (.+);
[Deploy Patterns]
®ister.contact.addrport = %1
$continue = true
-------------------------------------------------
Try this rule first.
-------------------------------------------------
[Matching Patterns]
$request = ^REGISTER
$transport = TCP
[Deploy Patterns]
®ister.contact.remote = true
$continue = true
-------------------------------------------------
If it doesn't work, remove it and try the next rule.
-------------------------------------------------
[Matching Patterns]
$request = ^REGISTER
Via = TCP (.+);
[Deploy Patterns]
®ister.contact.addrport = %1
$continue = true
-------------------------------------------------
Matching Patter
Thanks,
The first pattern mostly worked. I am able now able to make the incoming call. However, when I try to end the call I have the same problem of the bye not being acknowledged. I'm guessing this is because of the bye signaling has the same issue?
Just to make sure I understand the first dial plan rule. The matching pattern looks for all register requests using TCP, correct?
In the Deploy pattern, what does $register.contact.remote = true do?
Regards,
The first pattern mostly worked. I am able now able to make the incoming call. However, when I try to end the call I have the same problem of the bye not being acknowledged. I'm guessing this is because of the bye signaling has the same issue?
Just to make sure I understand the first dial plan rule. The matching pattern looks for all register requests using TCP, correct?
In the Deploy pattern, what does $register.contact.remote = true do?
Regards,
Brekeke Switching from TCP to UDP?
I think I might have found the problem. Both clients are registered using TCP. When I try to initiate a call from one of the TCP-registered clients, it sends the invite via TCP to Brekeke. However, when Brekeke forwards the invite to the destination client, it sends it out as a UDP packet.
Since the client was expecting UDP, it does not respond to the incoming call request. This looks like a bug on the Brekeke side?
Since the client was expecting UDP, it does not respond to the incoming call request. This looks like a bug on the Brekeke side?
> The matching pattern looks for all register requests using TCP,
> correct?
Yes
> In the Deploy pattern, what does $register.contact.remote = true do?
According to http://wiki.brekeke.com/wiki/BSS_History
®ister.contact.remote - If true, SIP server uses the remote IP address to reach UA instead of using Contact URI.
> correct?
Yes
> In the Deploy pattern, what does $register.contact.remote = true do?
According to http://wiki.brekeke.com/wiki/BSS_History
®ister.contact.remote - If true, SIP server uses the remote IP address to reach UA instead of using Contact URI.
> However, when Brekeke forwards the invite to the destination
> client, it sends it out as a UDP packet.
If the destination doesn't respond over TCP, Brekeke resends the INVITE over UDP.
Refer the "UDP Failover" in the document. Its default is "on".
> Since the client was expecting UDP
Is it "TCP", right?
> This looks like a bug on the Brekeke side?
I don't think so.
I uses Microsoft OCS + Brekeke over TCP, but there are no issues.
In my experience, the following rule should work.
-------------------------------------------------
[Matching Patterns]
$request = ^REGISTER
$transport = TCP
$getUri( Contact ) = @(.+)
[Deploy Patterns]
®ister.contact.addrport = %1
$continue = true
-------------------------------------------------
With this rule, the SIP Server sends the INVITE to the destination's Contact URI.
> client, it sends it out as a UDP packet.
If the destination doesn't respond over TCP, Brekeke resends the INVITE over UDP.
Refer the "UDP Failover" in the document. Its default is "on".
> Since the client was expecting UDP
Is it "TCP", right?
> This looks like a bug on the Brekeke side?
I don't think so.
I uses Microsoft OCS + Brekeke over TCP, but there are no issues.
In my experience, the following rule should work.
-------------------------------------------------
[Matching Patterns]
$request = ^REGISTER
$transport = TCP
$getUri( Contact ) = @(.+)
[Deploy Patterns]
®ister.contact.addrport = %1
$continue = true
-------------------------------------------------
With this rule, the SIP Server sends the INVITE to the destination's Contact URI.