[Spce-user] Fwd: Re: Blacklist t.38 fax codec

Fri Jun 20 10:13:21 EDT 2014

Your calling device is just canceling the call after ringing for 9 seconds.
The call is never actually established. T38 can only happen after 200 OK,
and that’s not happening in this call log

Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2403]: INFO: <script>: NAT-Reply -
S=100 - Connecting M=INVITE IP=154.58.3.158:5060 (127.0.0.1:5080)
ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2395]: INFO: <script>: NAT-Reply -
S=180 - Ringing M=INVITE IP=154.58.3.158:5060 (127.0.0.1:5080)
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2399]: INFO: <script>: New request
- M=CANCEL R=sip:984099519 at 154.58.3.135 F=sip:x1009 at 154.58.3.135
T=sip:984099519 at 154.58.3.135 IP=154.58.3.158:5060 (127.0.0.1:5060)
ID=15059 at 154.58.3.158

*From:* spce-user-bounces at lists.sipwise.com [mailto:
spce-user-bounces at lists.sipwise.com] *On Behalf Of *Leopoldo Iglesia
*Sent:* 20 June 2014 04:09 PM
*To:* spce-user at lists.sipwise.com
*Subject:* Re: [Spce-user] Fwd: Re: Blacklist t.38 fax codec

The log for kamailio-proxy tells this when I call , and client tries to
negotiate as fax....

Any ideas, apart from las post? Thanks

Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Setting PPI
to '<sip:984099520 at 154.58.3.135> <sip:984099520 at 154.58.3.135>' -
R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Prepare
Diversion setting - R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: No selector
set, not setting CLI - R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Prepare
History-Info setting - R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: No selector
set, not setting CLI - R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Applying
callee-out domain rewrite rules using dpid '4' -
R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: No matching
rewrite rules for 'x1008' found - R=sip:x1008 at 154.58.3.159:5060
ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Setting
P-Called-Party-ID '<sip:x1008 at 154.58.3.135> <sip:x1008 at 154.58.3.135>' -
R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Writing sbc
parameters  ;aleg_sst_enable=no;sst_enable=no -
R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Appending
P-D-URI 'sip:lb at 127.0.0.1;lr;socket='sip:154.58.3.135:5060'' -
R=sip:x1008 at 154.58.3.159:5060 ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Forcing
request via B2BUA 'sip:127.0.0.1:5080' - R=sip:x1008 at 154.58.3.159:5060
ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2391]: INFO: <script>: Request
leaving server, D-URI='sip:127.0.0.1:5080' - R=sip:x1008 at 154.58.3.159:5060
ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2403]: INFO: <script>: NAT-Reply -
S=100 - Connecting M=INVITE IP=154.58.3.158:5060 (127.0.0.1:5080)
ID=15059 at 154.58.3.158
Jun 19 10:36:43 SIPSW /usr/sbin/kamailio[2395]: INFO: <script>: NAT-Reply -
S=180 - Ringing M=INVITE IP=154.58.3.158:5060 (127.0.0.1:5080)
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2399]: INFO: <script>: New request
- M=CANCEL R=sip:984099519 at 154.58.3.135 F=sip:x1009 at 154.58.3.135
T=sip:984099519 at 154.58.3.135 IP=154.58.3.158:5060 (127.0.0.1:5060)
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2399]: INFO: <script>: Stop
mediaproxy for current branch using first Via - R=sip:984099519 at 154.58.3.135
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2399]: ERROR: rtpproxy-ng
[rtpproxy.c:1348]: proxy replied with error: Call-ID not found or tags
didn't match
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2399]: INFO: <script>: Request
leaving server via local route - R=sip:984099519 at 154.58.3.135
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2393]: INFO: <script>: NAT-Reply -
S=487 - Request terminated M=INVITE IP=154.58.3.158:5060 (127.0.0.1:5080)
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2393]: INFO: <script>: Failure
route for local call - R=sip:984099519 at 154.58.3.135 ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2393]: INFO: <script>: Stop
mediaproxy for current branch using first Via - R=sip:984099519 at 154.58.3.135
ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2393]: ERROR: rtpproxy-ng
[rtpproxy.c:1348]: proxy replied with error: Call-ID not found or tags
didn't match
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2393]: INFO: <script>: Final reply
- R=sip:984099519 at 154.58.3.135 ID=15059 at 154.58.3.158
Jun 19 10:36:52 SIPSW /usr/sbin/kamailio[2401]: INFO: <script>: New request
- M=ACK R=sip:984099519 at 154.58.3.135 F=sip:x1009 at 154.58.3.135
T=sip:984099519 at 154.58.3.135 IP=154.58.3.158:5060 (127.0.0.1:5060)
ID=15059 at 154.58.3.158

El 20/06/2014 14:24, Daniel Grotti escribió:

Could be,
as I see also the normal t38 negotiation is client-dependent....it

But from RFC3261:

 During the session, either Alice or Bob may decide to change the
   characteristics of the media session.  This is accomplished by
   sending a re-INVITE containing a new media description.  This re-
   INVITE references the existing dialog so that the other party knows
   that it is to modify an existing session instead of establishing a
   new session.  The other party sends a 200 (OK) to accept the change.
   The requestor responds to the 200 (OK) with an ACK.  If the other
   party does not accept the change, he sends an error response such as
   488 (Not Acceptable Here), which also receives an ACK.  However, the
   failure of the re-INVITE does not cause the existing call to fail -
   the session continues using the previously negotiated
   characteristics.

Daniel

On 06/20/2014 02:08 PM, Matthew Ogden wrote:

I think the problem is, a 488 will stop the call altogether?

I cant recall, but if you get a 488 in a REINVITE, will the call not
terminate after that, or does it “failback” to leaving t38 un-negotiated…
might be device dependent?

*From:* spce-user-bounces at lists.sipwise.com [mailto:
spce-user-bounces at lists.sipwise.com] *On Behalf Of *Leopoldo Iglesia
*Sent:* 20 June 2014 01:55 PM
*To:* spce-user at lists.sipwise.com
*Subject:* Re: [Spce-user] Fwd: Re: Blacklist t.38 fax codec

Ok. "has_totag" where is located ??

El 20/06/2014 13:35, Daniel Grotti escribió:

I have nothing ready to give you right now.
Basically on kamailio proxy you should match a Re-invite (using the
"has_totag") and check if SDP contains t38 headers/codec (just have a look
how the T38 reinvite looks like).
So, if you receive a re-invite with T38 headers into SDP, just send back a
488 reply.

Daniel

On 06/20/2014 01:28 PM, Leopoldo Iglesia wrote:

Fine, how can I do this hack? cause endpoints is impossible to mod config,
so they are rented and provisioned by an ftth operator.

El 20/06/2014 13:23, Daniel Grotti escribió:

Hi,
I think you need to avoid to forward the T38 Re-INVITE, so you should hack
your SPCE in order to reply to the T38 re-invite with a "488 Not acceptable
here", for example.
So the sender SHOULD fallback to G711.
Anyway, the best solution if you have endpoint with t38 enabled but they
don't work well, is to disable t38.

Daniel

On 06/20/2014 01:15 PM, Leopoldo Iglesia wrote:

> But both endpoints support it, that is the problem and the only >
scenario when it fails, so i want SPCE not to send Fax negotiation to >
endpoint,.

 El 20/06/2014 12:12, Daniel Grotti escribió: >> Hi, >> that's strange, if
one of the endpoints try to switch to t38 and the >> other endpoint doesn't
support it, they should fallback to G711. >> >> Daniel >> >> >> >> >> >> >>
On 06/20/2014 01:33 AM, Leopoldo Iglesia wrote: >>> How can I, blacklist
t.38 to avoid endpoints to try t38 negotiation? >>> >>> When i call from
ericcson ont to fax capable endpoint, it try to >>> connect t38 fax and
There is no voice. >>> >>> Thanks >>> >>> Leopoldo iglesia >>> >>>
_______________________________________________ >>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com >>>
http://lists.sipwise.com/listinfo/spce-user >> >>
_______________________________________________ >> Spce-user mailing list
>> Spce-user at lists.sipwise.com >>
http://lists.sipwise.com/listinfo/spce-user > >

_______________________________________________

Spce-user mailing list

Spce-user at lists.sipwise.com

http://lists.sipwise.com/listinfo/spce-user

_______________________________________________

Spce-user mailing list

Spce-user at lists.sipwise.com

http://lists.sipwise.com/listinfo/spce-user

_______________________________________________

Spce-user mailing list

Spce-user at lists.sipwise.com

http://lists.sipwise.com/listinfo/spce-user

_______________________________________________

Spce-user mailing list

Spce-user at lists.sipwise.com

http://lists.sipwise.com/listinfo/spce-user

_______________________________________________

Spce-user mailing list

Spce-user at lists.sipwise.com

http://lists.sipwise.com/listinfo/spce-user

_______________________________________________

Spce-user mailing list

Spce-user at lists.sipwise.com

http://lists.sipwise.com/listinfo/spce-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20140620/fb3938c0/attachment-0001.html>