Clients invite provokes early media? what am i doing wrong?

Asterisk Asterisk Support
1

Hey everyone,

I have a really strange issue I’d appreciate some advice on…

Basically, in a nutshell, I’m accidently committing FAS…! i.e. we indicate the call has started before it actually has, by sending a 200 OK before we’ve even invited

We use asterisk as a very small softswitch, which we use to supply SIP trunks to our clients for small amounts of traffic. So simply put the flow is …

Client/caller >>> Ourselves >>> our suppliers SIP Trunk >>> End user/callee

Below is a screenshot of the call flow I’m seeing (with IPs blocked for privacy! :smile: )…

877×430

As you can see, we correctly respond with 100 trying, at which point I would expect us to invite to the supplier.

But instead, we immediately give the client a 200OK, which they respond with an ACK, which effectively starts media.

From the clients point of view, the call has begun. And while I can appease the person actually using the phone with a ringback tone using the r function of the dial cmd, the clients reporting is all over the place. And so is ours.

Here’s a snippet of the clients sip.conf entry -

[clientsIpAddress] canreinvite=no context=clientsContext type=friend host=clientsIpAddress dtmfmode=rfc2833 disallow=all allow=g729 allow=ulaw allow=alaw nat=force_rport,comedia directrtpsetup=yes

And the extensions.conf…

[clientsContext] exten => _44414X.,1,Answer exten => _44414X.,2,Set(CALLERID(num)=${CALLERID(num)}) exten => _44414X.,3,Dial(SIP/68445${EXTEN:5}@suppliersIpAddress)

What I expect should be happening is something like

[code]Client/caller ourselves callerRtpServer Supplier
Invite >----------
------------------------------------------
--------------------------------<trying
--------------------------------<183 in progress
----------------200 ok <
ack >----------------

	rtp >>>>------------rtp <<<<

[/code]

We have another client, who uses exactly the same sip.conf and extension.conf setup, with a different IP and context. So the only think it can be, is the invite they send must have something in it that’s provoking it?

Here’s an invite from them, with private details removed.

[code]INVITE sip:CALLEDNUMBER@OURIPADDRESS:5060 SIP/2.0
Via: SIP/2.0/UDP CLIENTSIPADDRESS:5060;branch=z9hG4bK04B95740757c3e0c06b
From: sip:CALLERID@CLIENTSIPADDRESS;tag=gK046abe0d
To: sip:CALLEDNUMBER@OURIPADDRESS
Call-ID: 1694765950_70403541@CLIENTSIPADDRESS
CSeq: 31937 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: sip:CALLERID@CLIENTSIPADDRESS:5060
P-Preferred-Identity: sip:CALLERID@CLIENTSIPADDRESS:5060
Supported: timer,100rel,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 307
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 23892 30637 IN IP4 CLIENTSIPADDRESS
s=SIP Media Capabilities
c=IN IP4 CLIENTSMEDIASERVER
t=0 0
m=audio 16452 RTP/AVP 8 0 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20[/code]

so what can i do?! really lost here…!

2

You are explicitly answering the call. This is common bad practice. Don’t do it unless you really want to. (Replace Answer by Noop.)

Note that the outgoing side is using early media, but the incoming side is fully answered.

3

Note. Unless you are a recognized network operator, it is unlikely that you will achieve early media on the incoming side, so, if you don’t answer, callers will hear ringback during any incoming early media.

4

Wow… thanks David55.

I went well overboard on the diagnostic front. As you say, having Answer() is a bad habit I think I’ve put in by default from making ‘applications’ in dial plans that would require the answer.

It appears to have fixed the issue.

Thank you :smile: