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

Leopoldo Iglesia liglesia at por-aire.es
Fri Jun 20 10:08:41 EDT 2014


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>' - 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>' - 
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> 
>> [mailto: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 <mailto: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
>>                 <mailto:Spce-user at lists.sipwise.com> >>>
>>                 http://lists.sipwise.com/listinfo/spce-user >> >>
>>                 _______________________________________________ >>
>>                 Spce-user mailing list >> Spce-user at lists.sipwise.com
>>                 <mailto:Spce-user at lists.sipwise.com> >>
>>                 http://lists.sipwise.com/listinfo/spce-user > >
>>
>>
>>
>>
>>
>>                 _______________________________________________
>>
>>                 Spce-user mailing list
>>
>>                 Spce-user at lists.sipwise.com  <mailto:Spce-user at lists.sipwise.com>
>>
>>                 http://lists.sipwise.com/listinfo/spce-user
>>
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             Spce-user mailing list
>>
>>             Spce-user at lists.sipwise.com  <mailto:Spce-user at lists.sipwise.com>
>>
>>             http://lists.sipwise.com/listinfo/spce-user
>>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         Spce-user mailing list
>>
>>         Spce-user at lists.sipwise.com  <mailto:Spce-user at lists.sipwise.com>
>>
>>         http://lists.sipwise.com/listinfo/spce-user
>>
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     Spce-user mailing list
>>
>>     Spce-user at lists.sipwise.com  <mailto: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/317f8682/attachment-0001.html>


More information about the Spce-user mailing list