SIP - Direct Session Setup

Good evening everyone!

I’m a first time poster, however; based on some of my company’s upcoming projects, I’ll probably be here quite a bit!

Anyways, here is my problem:

I have a handset where once a session is established through the Proxy PBX and without a Record-route header, the PBX remains in the signaling path for the entire session.

I have another handset where each UA only uses the proxy for the session initiation. Once the session is established, the UAs communicate directly and independent of the PBX.

So what should I be looking for to explain why one handset operates in more of a stateful way and another operates in a more stateless way? I’ve been trying to come up with an answer to this for quite some time so that I can get these handsets to consistently work with my Asterisk box.

Thank you all in advance. Cheers!

Try

canreinvite=yes

Are all the configs for the handsets the same? (or are they even the same handsets)

They are different handsets using the same SIP stack.

What doesn’t make sense to me is that fact that all of the SIP messaging looks correct in each wireshark capture. However, one handset will negotiate an end-to-end call (the ACK is sent directly to the other handset/UA) and the other will still go through the proxy (the ACK is sent to the proxy first, and the proxy forwards it to the other handset).

I’ve examined each trace and they are identical. In most cases, from a SIP messaging perspective, I was always under the assumption that the UA parsed the Contact header for the callee’s URI, and then used this for the ACK where a direct session is set up.

Am I correct with this assumption? Thank you for the reply. Cheers!

Stays in the path without a record-route set? hmmm…little bit disobedient!
Sounds more a problem with the handset. Is it a chinese no-name handset?

What does the Via header say? This is where the message will be routed to. And if you have many legs it will say:

Via: machine@domain1;more sip stuff
machine@domain2;more sip stuff
machine@domain3;more sip stuff
To:
From:
Contact:

You can read more about it with reference to “SIP Loose Routing”

Check this out:
syslog.nu/node/3020 with 1.4.18 this person had a problem go away

Dunno what else to check out - sounds like a handset thing. Try with a softphone to test with - either zoiper or x-lite - they both seem to do a good job of behaving.

Cheers

LOL! I used X-lite as a comparison and the message structure was identical.
Here is the ACK:

ACK sip:0512@192.168.0.25:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.24:5060;rport;branch=z9hG4bK462895647
From: sip:0516@192.168.0.1;tag=929969082
To: sip:0512@192.168.0.1;tag=1006967023
Call-ID: 464984562@192.168.0.24
CSeq: 2 ACK
Contact: sip:0516@192.168.0.24:5060
Proxy-Authorization: Digest username=“0516”, realm=“00000013”, nonce=“3f32aa095a398825b6be782cb03ab6330f0722fcC0A4B00F9A50”, uri="sip:0512@192.168.0.1", response=“00933b8f2f84f286f978387c522143b7”, algorithm=MD5, cnonce=“1234567890”, qop=auth, nc=00000001
Max-Forwards: 70
User-Agent: NetCODEC
Supported: timer
Content-Length: 0

So I really don’t know what the problem is. From what I understand, the Via header includes where the message came from, not where it is going. Then again, I’m not really sure which is why i turned to these forums! :smile: Thanks again for your help. Cheers!

NOTE: For reference, here is the X-lite capture:

ACK sip:0513@192.168.0.26 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.30:50263;branch=z9hG4bK-d8754z-9dd2a837c3925721-1—d8754z-;rport
Max-Forwards: 70
Contact: sip:0511@192.168.0.30:50263
To: "0513"sip:0513@192.168.0.1;tag=796607764
From: “Nothing"sip:0511@192.168.0.1;tag=e9ccd338
Call-ID: ZDZkNTM2YTYwMjJiZDgzZTQ3OTAxZTM3ZDBkMTFkMjQ.
CSeq: 2 ACK
Proxy-Authorization: Digest username=“0511”,realm=“00000013”,nonce=“307cae6c1911cd04765b35d1a0fe0f2a494aadd8C0A4BABE81DC”,uri="sip:0513@192.168.0.1”,response=“71d807cd045efdecf50b19318fc87249”,cnonce=“8dd8ef1e427657db1e9bd12db6abf355”,nc=00000001,qop=auth,algorithm=MD5
User-Agent: X-Lite
Content-Length: 0

Which Proxy PBX? Asterisk is not a proxy, so will always stay in the signalling path (unless you use the Transfer application).