ReINVITE request/response proxying

1. Brekeke Product Name and version: 2.4.7.3/286.1
2. Java version: 1.6.0_22
3. OS type and the version: Windows XP
4. UA (phone), gateway or other hardware/software involved: ip500 IP/PBX
5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html : Pattern 1
6. Your problem:

We inserted the BSS between our SIP endpoint and the IP500 PBX, because our endpoint needs to register with the IP500 switch to accept calls on the station side, but our software doesn't recognize the REGISTER response OK packets, we believe because the contact binding in the response doesn't match that of the REGISTER packet. So we installed the BSS on our machine, put the sip endpoint at port 5061, put the BSS at 5060, used Upper Registration to complete the registration of the endpoint, and a dial plan that routes calls to the endpoint at port 5061. Works fine.

The problem comes during a transfer attempt from the endpoint; in this case, the endpoint at port 5061 issues a (re)INVITE packet to put the caller on hold. However, the Contact field for this routes from the BSS to the IP500 as from port 5060, and the response comes back to there, even though the From address shows the 5061 address. I'm not sure which party at that point is confused, or if the response packet isn't proxied, but the upshot is that the endpoint at 5061 never sees/processes the OK from the (re)INVITE, and so keeps repeating the request.

I've tried in vain to figure out how to rewrite the sip headers to make any difference here, and am not sure if that's even possible or the right solution. Has anyone else had and solved a similar issue with the BSS running on the same host as an endpoint at a different port?

Thanks in advance,
/Will

if both SIP Server and the IP500 PBX are on the same network, set the following.

net.sip.replacecontact = false

if there are NAT between both, set the following.

net.sip.replacecontact.nat = false


you can set these variables at [Configuration] > [Advanced] page.

The suggestions made didn't help, but I've set up a more testable system here in our lab, where I have the BSS on a separate machine from the endpoint software, and also from our gateway, so I can instrument both sides of the conversation and eliminate the whole port mapping issue.

I've run two wireshark traces, one with the BSS in the middle of the transfer attempt, and one without, and tried to play "one of these things is not like the others." AFAICT, the OK response to the on-hold INVITE has its From and To addresses both rewritten to be that of the BSS, rather than the originator of the INVITE and the gateway, respectively, as in the original INVITE request. The rest of the natting works properly, though, so I'm a bit puzzled as to why it behaves like this, let alone how to stop it.

Is there a list of the advanced parameters and their effects somewhere? (I can't seem to find them on-line or in the admin guides and the wiki is useless.)

FTR: I found the parameters for enabling verbose logging on the BSS, and searched the file system for the resulting logfile, and then located the packet relay log for this transaction in it.

The original reINVITE has the From and To fields set to the sip endpoint and the gateway address, respectively, but the packet is sent to the BSS; as the reINVITE is forwarded to the gateway, the From field is rewritten to that of the BSS. The OK response comes back to the BSS with the From and To being the BSS and gateway; as the OK is forwarded to the endpoint, the To field is similarly set to the BSS address. I believe our (3rd party) endpoint uses the From and To fields to verify that the response is a response to its original INVITE, and so it ignores it and retransmits, ad nauseum.

I would happily include the BSS trace here, but I think that might be against forum etiquette, and there's no place for attachments...

But, hopefully, given this information, someone can suggest a solution whereby the From and To values are not replaced?

Thanks in advance,
/Will

Try "$replaceuri = off" in the Deploy Pattern.

Thanks; that and getting the right matching pattern for the outbound INVITE requests did the trick. The part that (pleasantly) surprised me is that this deploy pattern affected both the request AND the response packets, since the unwanted rewrite was occurring on the proxied responses, not on the outbound request. (I had assumed that deployment pattern would only affect the request packets...)

Much appreciated!

Would you be so kind to post the Matching and Deploy Patterns? We're having an issue with one of our Providers. The others work but this one provider places the call on hold. We need to send a ReInvite so the call will go through. We use 5060 then send it to endpoint 5061. Thanks.

We're getting one-way calling, I can hear them, they can't hear me. It looks like a Call Hold (c=IN IP40.0.0.0) and waiting for a reInvite. a=inactive and is suppose to be a=sendrcv.

It's been days so I'm hitting a brick wall. Any help would be much appreciated.

Here's our current DP:

Matching Pattern:

$request=^INVITE
To=sip:<DID number>@
From=(.+)@(.+)>

Deploy Pattern:

$auth=false
To=sip:<destination number>@<dest IP address>:5061
From="caller ID"<sip:caller id@%2>


Here's what our DID provider saw:

v=0
o=HuaweiSoftX3000 970428 970428 IN IP4 64.x.x.x <our PBX IP>
s=Sip Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
a=inactive

Sure, but I'm not sure it will be applicable to your situation...

The following is our the exported dialplan; note that in this example, the PBX is at 10.36.21.102, and the BSS and the endpoint are both on 10.36.21.105; we use the BSS to reroute to the endpoint listening at port 5061. When it comes time to transfer the call, our endpoint, our endpoint is requesting the hold (using reINVITE, with SDP of 0.0.0.0) *To* the PBX, then doing a REFER on the held call after the hold is completed.

"Inbound Calls", $request="INVITE";$geturi(From)="sip:.*@10.36.21.102";, To="sip:2800@10.36.21.105:5061";$replaceuri="false", "trivial dial plan"
"Outbound Invites", $Request="INVITE";To=".*<sip:.*@10.36.21.102>.*";, $replaceuri.To="false", "stop rewrite of To field in response OK for on-hold."

(Hope this helps.)
/Will

Thanks, WSAdkin.

What about the Deploy Pattern? You can take out the IPs. Thanks so much for your help and quick response. I will try it once I see and understand the Deploy Pattern.

Sorry, saw the Deploy Pattern after cleaning it up. Will try it and let you know. Thanks, again, Will.

Sorry; the deploy patterns were there in the exported dialplan; I'll reformat to match yours:
I'm not sure if this will help you, but I strongly suggest using wireshark to look at the packet traffic between your provider and the BSS, set net.sip.loglevel.file=255 in the Advanced BSS parameters, and then restart the BSS to enable logging between ports 5060 and 5061 on your local host. (The logs appear to end up in ...Brekeke\proxy\webapps\proxy\WEB-INF\work\sv\log\<year>\<month>\sv.<datetime>.log files)

With this latter log, you should be able to piece together EXACTLY what is happening SIP packet-wise between the three players in the conversation.

Again, hope this helps!
/Will

K, thanks ... will try it.