[Spce-user] Remove SDP media-level attribute - direction
Maximilian Gerhardt
m.gerhardt at hall.ag
Mon May 13 11:28:07 EDT 2013
And you also sending with T.38.
I dont know what Asterisk Versions you are using but check this:
* Asterisk 1.2 has no support for T.38.
* Asterisk 1.4 supports only T.38 fax pass through; there is however a third party way<http://www.voip-info.org/wiki/view/T38modem+configuration+with+Asterisk> using HylaFax and OPAL to send and receive fax through Asterisk 1.4. See also rejected patch 12931<http://bugs.digium.com/view.php?id=12931> that includes a T.38 gateway. Attractel<http://www.attractel.com/t38.html> offers a commercial T.38 gateway solution for Asterisk.
* In Asterisk 1.6 also origination and termination features will be added (with gateway functionality still missing)
* NEW: In 2009 Digium introduced the commercial "Fax for Asterisk" with T.38 support (free licence for 1 channel)
* For Asterisk 1.8 exist T.38 Gateway patch http://bugs.digium.com/view.php?id=13405
* In Asterisk 10 is Asterisk T.38 Gateway<http://www.voip-info.org/wiki/view/Asterisk+T.38+Gateway> integrated
Regards,
Max
Von: spce-user-bounces at lists.sipwise.com [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Mario Contreras
Gesendet: Montag, 13. Mai 2013 17:21
An: Imanol Pardavila
Cc: spce-user at lists.sipwise.com
Betreff: Re: [Spce-user] Remove SDP media-level attribute - direction
Hi all.
Sorry for reopen this old thread. I can't remove that line from body. I have two asterisks, which I use for sending and receiving fax, but it's not working, and I'm not sure why. This is the caller leg conversation:
[cid:part1.04020200.05000100 at innovasur.es]
And the log in asterisk(the one sending 488), show this:
[May 13 17:02:32] DEBUG[1911] chan_sip.c: Initializing initreq for method INVITE - callid 713319c15c67f95e34adee3c59efc3bf at domain
[May 13 17:02:32] DEBUG[1911] chan_sip.c: Trying to put 'INVITE sip:' onto UDP socket destined for IP_SPCE:5060
[May 13 17:02:32] VERBOSE[1911] app_dial.c: -- Called sip/911111111 at fax
[May 13 17:02:32] DEBUG[1911] channel.c: Set channel SIP/fax-00000008 to read format slin
[May 13 17:02:32] DEBUG[1911] channel.c: Set channel SIP/fax-00000008 to write format slin
[May 13 17:02:32] DEBUG[31087] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '713319c15c67f95e34adee3c59efc3bf at domain
...skipping...
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing session-level SDP c=IN IP4 46.39.192.6... OK.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing session-level SDP t=0 0... UNSUPPORTED.
[May 13 17:02:36] VERBOSE[31087] netsock.c: == Using UDPTL CoS mark 5
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Setting NAT on UDPTL to Off
[May 13 17:02:36] DEBUG[31087] chan_sip.c: FaxVersion: 0
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=T38FaxVersion:0... OK.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: T38MaxBitRate: 14400
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=T38MaxBitRate:14400... OK.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: RateManagement: transferredTCF
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=T38FaxRateManagement:transferredTCF... OK.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: FaxMaxDatagram: 849
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=T38FaxMaxDatagram:849... OK.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: UDP EC: t38UDPFEC
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=T38FaxUdpEC:t38UDPFEC... OK.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=direction:active... UNSUPPORTED.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Processing media-level (image) SDP a=nortpproxy:yes... UNSUPPORTED.
[May 13 17:02:36] DEBUG[31087] chan_sip.c: T38 state changed to 2 on channel SIP/fax-00000008
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Have T.38 but no audio, accepting offer anyway
[May 13 17:02:36] DEBUG[31087] chan_sip.c: SIP/fax-00000008: This call is UP....
[May 13 17:02:36] DEBUG[31087] chan_sip.c: Trying to put 'SIP/2.0 100' onto UDP socket destined for IP_SPCE:5060
[May 13 17:02:36] DEBUG[1910] chan_sip.c: T38 state changed to 4 on channel SIP/fax-00000008
[May 13 17:02:36] DEBUG[1910] chan_sip.c: Trying to put 'SIP/2.0 488' onto UDP socket destined for IP_SPCE:5060
I think it's caused by these lines:
direction:active
nortpproxy:yes
That attributes are created in spce, not in asterisk. Anyway, like I've said, I've tried the modification made by Imanol, but although in kamailio-proxy log appears "Rewriting T.38 'UDPTL' to 'udptl'", the line is still in body.
Any ideas? Thanks!
El 19/11/2012 18:35, Imanol Pardavila escribió:
Hi everybody,
Finally it works!.
If somebody has the same problem, I inserted the modification in two places:
/etc/ngcp-config/templates/etc/kamailio/proxy/proxy.cfg.customtt.tt2
########################################################################
# Reply route 'base-nat-reply'
########################################################################
onreply_route[REPLY_ROUTE_NAT]
{
xlog("L_INFO", "NAT-Reply - [% logres_init -%]\n");
force_rport();
if(has_body("application/sdp") && ($avp(s:from_faxserver) == 1 || $avp(s:to_faxserver) == 1))
{
# fix for T.38 to patton faxserver gateway, which chokes on upper-case
xlog("L_INFO", "Rewriting T.38 'UDPTL' to 'udptl' - [% logres -%]\n");
replace_body_all(" UDPTL ", " udptl ");
}
if(has_body("application/sdp"))
{
# fix SDP direction attribute for Sonus SBC
xlog("L_INFO", "Removing direction attribute from SDP - [% logreq -%]\n");
replace_body_all("a=direction:active\r?\n", "");
}
if(status=~"(180)|(183)|2[0-9][0-9]")
...
...
########################################################################
# Branch route 'cli-rtp'
########################################################################
branch_route[BRANCH_ROUTE_CLI_RTP]
...
...
if($avp(s:callee_uuid) != $null && !is_present_hf("P-Callee-UUID"))
{
xlog("L_INFO", "Setting P-Callee-UUID to '$avp(s:callee_uuid)' - [% logreq -%]\n");
append_hf("P-Callee-UUID: $avp(s:callee_uuid)\r\n");
}
if(has_body("application/sdp"))
{
# fix SDP direction attribute for Sonus SBC
xlog("L_INFO", "Removing direction attribute from SDP - [% logreq -%]\n");
replace_body_all("a=direction:active\r?\n", "");
}
xlog("L_INFO", "Request leaving server, D-URI='$du' - [% logreq -%]\n");
}
I hope it would be helpful for somebody.
Thanks Andreas
Best regards
Imanol
El 14/11/2012 10:20, Andreas Granig escribió:
Hi,
You might want to remove the newline as well, like this:
replace_body_all("a=directmedia:active\r?\n", "");
Andreas
On 11/14/2012 10:12 AM, Imanol Pardavila wrote:
Hi,
I was able to remove the directionline, but the problem is that it
leaves an empty line between ptime and oldmediaip and SBC returns "400
Bad Request"due to malformed INVITE:
a=sendrecv
a=ptime:20
a=oldmediaip:10.34.240.60
a=nortpproxy:yes
I tried both:
replace_body_all("a=direction:active" ,"");
replace_body_all("a=direction:active" ,"");
with same result.
How could I remove the empty line?
Thanks
Best regards
Imanol
El 09/11/2012 14:05, Imanol Pardavila escribió:
Hi Andreas,
"kamailio.cfg.tt2" file has the following main structure:
route
...
route[ROUTE_RELAY]
...
route[ROUTE_REQUEST]
...
onreply_route
...
onsend_route
...
I guess that I have to insert something like this:
if(has_body("application/sdp")
{
# fix for Sonus SBC - remove directmedia attribute
xlog("L_INFO", "Removing directmedia attribute - [% logreq -%]\n");
replace_body_all(" a=directmedia:active ", "");
}
But I'm not sure about where to insert it. Could you help me?
Thanks
Best regards
Imanol
El 09/11/2012 12:45, Andreas Granig escribió:
Hi Imanol,
Oh, right, it's added by the proxy then after mediaproxy is engaged. So
the best place would be the load-balancer config at
/etc/ngcp-config/templates/etc/kamailio/lb/kamailio.cfg.customtt.tt2.
Andreas
On 11/09/2012 11:49 AM, Imanol Pardavila wrote:
Hi Andreas,
Looking at my traces I'm sure that endpoints aren't sending this
attribute; I've just filtered the first packet with this line on SDP
body and it's been sent by CE.
* SDP sent from our SBC to CE:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): Sonus_UAC IN IP4 10.34.241.67
Session Name (s): SIP Media Capabilities
Connection Information (c): IN IP4 10.34.240.60
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 1552 RTP/AVP
0 8 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv
Media Attribute (a): ptime:20
* SDP sent from CE to our SBC (following packet in the sequence):
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): Sonus_UAC IN IP4 10.34.242.11
Session Name (s): SIP Media Capabilities
Connection Information (c): IN IP4 10.34.242.11
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 30132 RTP/AVP
0 8 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv
Media Attribute (a): ptime:20
*Media Attribute (a): direction:active**
** Media Attribute (a): oldmediaip:10.34.240.60**
** Media Attribute (a): nortpproxy:yes*
Flow diagram:
|endpoint A| ------------- |SBC| ------------- |CE| ------------- |SBC|
------------- |endpoint B|
SBC: 10.34.240.60, 10.34.241.67
CE: 10.34.242.11
Any ideas?
Thanks
Best regards
Imanol
El 08/11/2012 20:22, Andreas Granig escribió:
Hi,
On 11/08/2012 05:25 PM, Imanol Pardavila wrote:
I'm not sure about who builds SDP? lb, proxy, sems? I guess that the
The SDP is created by the endpoints, not by the CE.
idea is create my customtt.tt2 file and use replace_body_all () function
something like:
# remove direction attribute
replace_body_all(" a=directmedia:active ", "");
Is it correct?
Not sure about the whitespaces, you might need to leave them out I guess.
Andreas
_______________________________________________
Spce-user mailing list
Spce-user at lists.sipwise.com<mailto:Spce-user at lists.sipwise.com>
http://lists.sipwise.com/listinfo/spce-user
-----
No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.2221 / Base de datos de virus: 2441/5382 - Fecha de publicacion: 11/08/12
_______________________________________________
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
-----
No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.2221 / Base de datos de virus: 2441/5383 - Fecha de publicacion: 11/08/12
_______________________________________________
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
-----
No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.2221 / Base de datos de virus: 2441/5393 - Fecha de publicacion: 11/13/12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130513/fbe1f73d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10023 bytes
Desc: image001.png
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130513/fbe1f73d/attachment-0001.png>
More information about the Spce-user
mailing list