SIP Trunking. Call transfer, can't force SDP in INVITE from 3300

[wyeee]

3300 Rel 4.2. SIP Trunking.

Incoming call from PSTN gateway to 3300 ext A is transferred to ext B.
When A press the transfer key, an INVITE is sent out (without SDP). And when 200 OK is received, ACK from 3300 contains SDP of IP 0.0.0.0.

My  PSTN gateway doesn't like INVITE without SDP. And the result of the transfer is I get one way voice.

I changed following settings on 3300:

SIP Peer Profile
  Force Sending SDP in Initial Invite Message : Yes
  Force Sending SDP in Initial Invite - Early Answer: Yes

SIP Device Capabilites
  Force Sending SDP in Initial Invite Message : Yes

I thought these should force 3300 to send SDP in the INVITE message.
But it still doesn't.

Anyone sees similar things?
Thanks

[brantn]

I would just set one of the early answer options as well as since I believe MCD and maybe before there is an option to prevent the 0.0.0.0 in sdp.

[wyeee]

OK, I set the following (besides the forcing SDP settings above) in SIP Peer Profile:

 Prevent the Use of IP Address of 0.0.0.0 in SDP Messages: Yes

Now the INVITE from 3300 for xfer still doesn't have SDP. The ACK message, instead of using IP 0.0.0.0, uses the real IP (c=IN IP4 192.168.80.143), which is the IP for 3300.

[brantn]

So it is no longer sending an invalid sdp. What is the problem you are having besides try to dechiper sip signalling? I would be more than happy to look at the wireshark if you want to pm me.

[wyeee]

The problem is my PSTN gateway doesn't like INVITE with no SDP. If I change to a PSTN gateway that could handle INVITE without SDP, then everything is fine.
I just thought by setting those flags, 3300 is forced to send out SDP with INVITE.
Thanks for your time. Really appreciate!

[brantn]

What are you using for a pstn gateway? The Mitel does send an sdp with the private address, dns address, or 0.0.0.0 in some occasion unless prohibited.

Here is an edited copy of a call with no transfer ...

Initial invite:

INVITE sip:blank@1.1.1.1 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4c88f7a994f2db72f130519551c5fedc.0
From: WIRELESS CALLER <sip:blank@blank:5060>;tag=A7C2.9B55
To: <sip:blank@blank:7061>
Call-ID: 0026.9E9B.B4F2.4DD2.A7C2.1B5A
CSeq: 8738 INVITE
Max-Forwards: 69
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4DD2.A7C2.9B558738.A48B6018.00001B95.zCp3O4Kz4K+KbJ34qyDi3Q__
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4DD2.A7C2.9B558738.-aN6AgMoWp89KmEvOe6hxw__
Contact: <sip:e4coEs7GA1Rbz1_ILEA3EVBH-hVHznloebVs7mglKAoOk-M9uL0tNDEQTg1c2kZ7r@1.2.3.4>
Session-Expires: 1800;refresher=uac
Allow: INVITE,BYE,INFO,PRACK,CANCEL,ACK,OPTIONS,SUBSCRIBE,NOTIFY,REGISTER,REFER,UPDATE
Supported: timer,100rel
Content-Type: application/sdp
Content-Length: 252
Record-Route: <sip:7c5669fe4b5976c9@1.2.3.4;lr>

v=0
o=BroadSoft 25576 25576 IN IP4 1.2.3.4 (Public SDP Owner)
s=M6 Call
c=IN IP4 1.2.3.4
t=0 0
m=audio 58238 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off - - - -
a=ptime:20
a=maxptime:40

200 OK:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4c88f7a994f2db72f130519551c5fedc.0,SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4DD2.A7C2.9B558738.A48B6018.00001B95.zCp3O4Kz4K+KbJ34qyDi3Q__,SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK4DD2.A7C2.9B558738.-aN6AgMoWp89KmEvOe6hxw__
Record-Route: <sip:7c5669fe4b5976c9@1.2.3.4;lr>
From: WIRELESS CALLER <sip:blank@blank:5060>;tag=A7C2.9B55
To: <sip:blank@blank:7061>;tag=0_2334818960-92952406
Call-ID: 0026.9E9B.B4F2.4DD2.A7C2.1B5A
CSeq: 8738 INVITE
Supported: timer
Contact: <sip:blank@1.1.1.1:5060;transport=udp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Content-Type: application/sdp
User-Agent: Mitel-3300-ICP 10.0.1.21
Content-Length: 162

v=0
o=- 9119 9119 IN IP4 1.2.3.4 (Private SDP Owner Proxies' 200 OK Shows Public)
s=-
c=IN IP4 1.2.3.40
t=0 0
m=audio 50278 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

I have found thru a lot of SIP work it is very wise to use an Ingate proxy as it helps to fix some of the signalling issues that you see between pbxs and soft switches. It also does the nat translation or routing which some firewalls even ones claiming to be sip aware fail on.