[Spce-user] Remove SDP media-level attribute - direction
Mario Contreras
mario.contreras at innovasur.es
Mon May 13 11:21:02 EDT 2013
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:
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
>>>>>>> http://lists.sipwise.com/listinfo/spce-user
>>>>>>>
>>>>>>>
>>>>>>> -----
>>>>>>> No se encontraron virus en este mensaje.
>>>>>>> Comprobado por AVG -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
>>>>>> http://lists.sipwise.com/listinfo/spce-user
>>>>>>
>>>>> _______________________________________________
>>>>> Spce-user mailing list
>>>>> 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
>>>>> 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
>>> http://lists.sipwise.com/listinfo/spce-user
>>>
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> 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
>> 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/mailman/private/spce-user_lists.sipwise.com/attachments/20130513/f525c9e5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eghhaefj.png
Type: image/png
Size: 10023 bytes
Desc: not available
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20130513/f525c9e5/attachment.png>
More information about the Spce-user
mailing list