Hello,
you are using it with some rtp relay function. Remove the codec, then do
msg_apply_changes() (all this before doing record route), then do the
rtp relaying.
Cheers,
Daniel
On 07/04/14 12:01, Oliver Roth wrote:
Here we go
IN
INVITE sip:41442742931@81.7.235.180:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 82.197.185.185;branch=z9hG4bKa368.02f63ac6.0
Via: SIP/2.0/UDP
195.216.67.103:5060;branch=z9hG4bK008082590C36C1313E749FCBA4C6
Route: <sip:82.197.185.186;lr=on>
From:
<sip:+41446512001@195.216.67.103;user=phone>;tag=008082590C36C1313BF6EF12E7F2
To: <sip:+41442742931@82.197.185.185;user=phone>;tag=snl_0014532334
Call-ID: e43880005082-533eb654-10953444-55d4a80-6bc5dd(a)127.0.0.1
CSeq: 5466 INVITE
Contact: <sip:+41446512001@195.216.67.103:5060>
Max-Forwards: 69
Content-Type: application/sdp
Session-Expires: 1800;refresher=uas
Supported: 100rel, timer, replaces
Content-Length: 330
v=0
o=- 82545395 2 IN IP4 195.216.67.103
s=session
t=0 0
m=audio 4550 RTP/AVP 8 0
c=IN IP4 195.216.67.120
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv
m=image 4552 udptl t38
c=IN IP4 195.216.67.120
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxUdpEC:t38UDPRedundancy
a=T38FaxRateManagement:transferredTCF
OUT
INVITE sip:41442742931@81.7.235.180:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 82.197.185.186;branch=z9hG4bKa368.aca64b5.0
Via: SIP/2.0/UDP 82.197.185.185;branch=z9hG4bKa368.02f63ac6.0
Via: SIP/2.0/UDP
195.216.67.103:5060;branch=z9hG4bK008082590C36C1313E749FCBA4C6
From:
<sip:+41446512001@195.216.67.103;user=phone>;tag=008082590C36C1313BF6EF12E7F2
To: <sip:+41442742931@82.197.185.185;user=phone>;tag=snl_0014532334
Call-ID: e43880005082-533eb654-10953444-55d4a80-6bc5dd(a)127.0.0.1
CSeq: 5466 INVITE
Contact: <sip:+41446512001@195.216.67.103:5060>
Max-Forwards: 68
Content-Type: application/sdp
Session-Expires: 1800;refresher=uas
Supported: 100rel, timer, replaces
Content-Length: 188
v=0
o=- 82545395 2 IN IP4 82.197.185.186
s=session
t=0 0
m=audio 64748 RTP/AVP 8 0
c=IN IP4 82.197.185.186
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=sendrecv
5037682.197.185.186
*Von:*sr-users-bounces@lists.sip-router.org
[mailto:sr-users-bounces@lists.sip-router.org] *Im Auftrag von
*Daniel-Constantin Mierla
*Gesendet:* Montag, 7. April 2014 10:40
*An:* Kamailio (SER) - Users Mailing List
*Betreff:* Re: [SR-Users] kamailio / rtpproxy - remove codec
Hello,
can you give the incoming sdp and outgoing sdp (both as text) when you
are using sdp_remove_media, to see what gets malformed there?
Cheers,
Daniel
On 07/04/14 08:37, Oliver Roth wrote:
Hi all
We use kamailio 3.3.7 and rtpproxy for enduser call-termination.
In case of a fax call, we get an invite from our carrier for
codecs G711a/u and T38.
As our termination carrier does not support T38 and because the
invite contains G711 and T38 we get back error 488.
How is it possible to remove the whole T38 part of this invite?
We tried
sdp_remove_codecs_by_name(list) without success – what “name”
should we use for T38? [T38, t38, t.38, T.38, …]
sdp_remove_line_by_prefix(string)
sdp_remove_media(type)
None of these functions did really work – best was the last one
with type=image but then the sip header is malformed.
As we saw with Kamailio version 4.1.x there are a lot of new
functions within sdpops. Would an upgrade help?
So basically the question is:
How to remove the t38 part of the fax invite? (see attachment)
KR,
Oli
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda>
-http://www.linkedin.com/in/miconda
Kamailio World Conference - April 2-4, 2014, Berlin, Germany
http://www.kamailioworld.com
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio World Conference - April 2-4, 2014, Berlin, Germany
http://www.kamailioworld.com