[Freeswitch-users] Sipura Codec Problem
Hi, I'm having a problem with a Sipura, it is sending for the G729 the tag "G729a" witch is not correct due the RFC. Media Attribute (a): rtpmap:18 G729a/8000 FS is returning (200OK) Media Attribute (a): rtpmap:96 G729/8000 I think that the problem is that FS is not matching the codec, so it returns the first dynamic payload which is 96. I think that I've seen post with a similar issue, and the solution was to change the tag before it hit the switch, so, what I've done is to change the "switch_r_sdp" (I have the rest of the parameters correct due I also use it to dynamically change the codecs order) and it's changing the SDP, but when FS sends the 200OK it is returning to the endpoint: Media Attribute (a): rtpmap:96 G729/8000 Which is exactly the same problem that I have without the transformation of the SDP. Is it correct? Do I have another solution? Thanks ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Sipura Codec Problem
Yes, that was my first option, but there many endpoints that I'm not able to configure. Basically it's a broadband solution where I have like 1000 endpoints that are out of my provisioning. Thanks, M On 03/11/2009, at 14:58, Brian West wrote: > FIx your sipura to NOT include the a in the codec its in the admin > section of the UI on the ATA. > > /b > > On Nov 3, 2009, at 11:47 AM, Mariano de Llano wrote: > >> Hi, >> >> I'm having a problem with a Sipura, it is sending for the G729 the >> tag "G729a" witch is not correct due the RFC. >> >> Media Attribute (a): rtpmap:18 G729a/8000 >> >> FS is returning (200OK) >> >> Media Attribute (a): rtpmap:96 G729/8000 >> >> I think that the problem is that FS is not matching the codec, so it >> returns the first dynamic payload which is 96. >> >> I think that I've seen post with a similar issue, and the solution >> was >> to change the tag before it hit the switch, so, what I've done is to >> change the "switch_r_sdp" (I have the rest of the parameters correct >> due I also use it to dynamically change the codecs order) and it's >> changing the SDP, but when FS sends the 200OK it is returning to the >> endpoint: >> >> Media Attribute (a): rtpmap:96 G729/8000 >> >> Which is exactly the same problem that I have without the >> transformation of the SDP. >> >> Is it correct? Do I have another solution? >> >> Thanks >> > > > ___ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] "Proxy|Bypass Media" Wrong Payload.
I'm sure of that. But I was talking about how is handle the parse of the packet not the process, and also I was referring to the case when FS is actually handling the media (proxy-media=false && bypass_media=false) as I said before FS ignores the las parameter in the rtrpmap when is handling the media, so, I'm quite sure that something can be done in order to make it work when is not handling it. I understand that is not a FS bug, however since it have different behavior depending on the media mode something is not working properly. On 29/09/2009, at 10:14, Brian West wrote: > NO, proxy media and bypass media are wildly different behaviors and do > process things a little differently. > > /b > > On Sep 29, 2009, at 12:40 AM, Mariano de Llano wrote: > >> it seams very weird to me >> that Sofia uses different approach to parse the mappings depending if >> it is handling or not the media (Perhaps is ignoring it and using a >> correct one). > > > ___ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] "Proxy|Bypass Media" Wrong Payload.
Thanks for the response. I've already seen what you are referring to, however when FS is handling the media and the AddPac does exactly the same, everything works fine, so I assumed that sofia is ignoring the las part of the map, and that is why I said that theoretically the capture was correct. I will take a look at the code, it seams very weird to me that Sofia uses different approach to parse the mappings depending if it is handling or not the media (Perhaps is ignoring it and using a correct one). What do you suggest me to do? (Use a hammer with my 3K AddPacs it's not an option) :D Thanks Regards, M On 29/09/2009, ta 01:41, Brian West wrote: > That would be I suspect because your AddPac gateway is BROKEN. I have > no idea why it would be saying PCMU/8000/3 unless its horribly > broken. The SOA in sofia is moving the answer to 96 because that SDP > is not valid for 0 which is a single channel of ulaw. I don't know > about you but I have yet to see a gateway able to do three channels of > PCMU :P > > /b > > On Sep 28, 2009, at 11:08 PM, Mariano de Llano wrote: > >> v=0 >> o=9499 1254144425 1254144425 IN IP4 [AddPac IP] >> s=AddPac Gateway SDP >> c=IN IP4 [AddPac IP] >> t=1254144425 0 >> m=audio 23004 RTP/AVP 0 101 >> a=ptime:20 >> a=rtpmap:0 PCMU/8000/3 >> a=rtpmap:101 telephone-event/8000/1 >> a=fmtp:101 0-15 >> > > > ___ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] "Proxy|Bypass Media" Wrong Payload.
Hi,
I'm having a strange behavior with the FS when I'm using it with
"inboud-late-negotiation=true" and with the both scenarios "proxy-
media=true" or "bypass-media=true". The FS is acting as a pseudo
proxy (I know that it is not intend for that).
The configuration is similar to this:
[Endpoints] <= a => [FS1] <= b => [FS2]
Where FS1 is acting as a proxy and registrar. The other one will
simply handle the calls between endpoints or with a Gateway.
Basically the problem is when I'm trying to call to an AddPac
Endpoint, then FS2 sends a call to the FS1 and this one do the proxy
or bypass process. Everything works fine with most of the UA
(Grandstream/Sipura/Linksys/Xlite/Zoiper/etc) but with the AddPac the
FS1 is returning a Payload 96 which seams to be wrong. The only
different (In Comparison to the other UA) that I've seen is the
"a=ptime:20" in the 200/OK/SDP witch is teorically right. I've seen
some posts with a similar issue las year: http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg01468.html
Another interesting point is when the media is handle by FS1 ("proxy-
media=false"|"bypass-media=false") everything works fine. Also, what
is more weird is when the call is generated by the AddPac the SDP
everything works fine too.
Probably is an AddPac issue, due is the only one failing, however
since I have not found something wrong in the SIP capture I'm
starting to have my doubts...
I'm running Freeswitch 1.0.4pre9.
Here is a small flow of the call:
1) FS2 INVITE TO FS1
2) FS1 INVITE TO AddPac Endpoint
3) AddPac Endpoint responds 200 with apparently correct SDP.
4) FS1 responds 200/OK with an Incorrect Payload
Here are the corresponding SIP packet trace with the previous call
flow:
Packet 1
===
INVITE sip:9...@[fs1 IP] SIP/2.0
Via: SIP/2.0/UDP [FS2 IP]:5060;branch=z9hG4bK60c74dbf;rport
From: "[Source Number]" ;tag=as3bd06925
To:
Contact:
Call-ID: 14b07c2014d3a0aa7719efa03d979...@[fs2 IP]
CSeq: 102 INVITE
User-Agent: Legacy
Max-Forwards: 70
Remote-Party-ID: "[Source Number]" IP]>;privacy=off;screen=no
Date: Mon, 28 Sep 2009 15:28:19 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 240
v=0
o=root 16330 16330 IN IP4 [FS2 IP]
s=session
c=IN IP4 [FS2 IP]
t=0 0
m=audio 12558 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
Packet 2
===
INVITE sip:9...@[addpac IP] SIP/2.0
Via: SIP/2.0/UDP [FS1 IP];rport;branch=z9hG4bKXt9pr4er2H2Np
Max-Forwards: 69
From: "[Source Number]" ;tag=7ZDB1S0pFpSja
To:
Call-ID: 765f438b-26e6-122d-3490-51d73cb8d94c
CSeq: 120957528 INVITE
Contact:
User-Agent: Proxy 1.1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, call-info, sla, include-session-
description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 228
Remote-Party-ID: <[Source Number]>
v=0
o=root 16330 16330 IN IP4 [FS2 IP]
s=session
c=IN IP4 [FS1 IP]
t=0 0
m=audio 27382 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
Packet 3
===
SIP/2.0 200 OK
Via: SIP/2.0/UDP [FS1 IP];rport;branch=z9hG4bKXt9pr4er2H2Np
From: "[Source Number]" ;tag=7ZDB1S0pFpSja
To: ;tag=a34a0003a4
Call-ID: 765f438b-26e6-122d-3490-51d73cb8d94c
CSeq: 120957528 INVITE
Supported: timer, replaces, early-session
User-Agent: AddPac SIP Gateway
Contact: sip:9...@[addpac IP]
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REFER, NOTIFY, INFO
Content-Type: application/sdp
Content-Length: 235
v=0
o=9499 1254144425 1254144425 IN IP4 [AddPac IP]
s=AddPac Gateway SDP
c=IN IP4 [AddPac IP]
t=1254144425 0
m=audio 23004 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000/3
a=rtpmap:101 telephone-event/8000/1
a=fmtp:101 0-15
Packet 4
===
SIP/2.0 200 OK
Via: SIP/2.0/UDP [FS2 IP]:5060;branch=z9hG4bK60c74dbf;rport=5060
From: "[Source Number]" ;tag=as3bd06925
To: ;tag=6pmjZyFKjD3Ze
Call-ID: 14b07c2014d3a0aa7719efa03d979...@[fs2 IP]
CSeq: 102 INVITE
Contact:
User-Agent: Proxy 1.1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, call-info, sla, include-session-
description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 221
v=0
o=9499 1254144425 1254144425 IN IP4 [AddPac IP]
s=AddPac Gateway SDP
c=IN IP4 [FS1 IP]
t=1254144425 0
m=audio 0 RTP/AVP 96 101
a=rtpmap:96 PCMU/8000/3
a=rtpmap:101 telephone-event/8000/1
a=fmtp:101 0-15
ACK sip:mod_so...@[fs1 IP]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP [FS2 I
Re: [Freeswitch-users] Can it do it?
You are right, it seams that it can not be done. In the past I've tried to do something similiar but with no success. Apperently the documentation is wrong. If I have some time I will look at the code and I will give you some feedback. Cheers, PS: The transcoding question has nothing to do with your question :) On 19/06/2009, at 17:18, JuanMa wrote: > I'm sorry, but like I said, I DONT WANT to do transcoding with FS(I > have another switch who is in charge of it, witch is from another > technology), I only want to negotiate the codecs in the way that I > want it. This only seams to work when bypass media or proxy media is > set to false. Due I need to use it as a SBC(session border controller) > or pseudo proxy (I already know that is not intend for it), I need to > negotiate the codecs in the FS. In the current thread I've already > explained what I'm trying to do. If you give me a tip I'm willing to > make the documentation richer. > > Thanks > Regards > > In my architecture the switch who is in charge of transcoding IS NOT a > FS. > > > On 19/06/2009, at 16:19, Brian West wrote: > >> No right now you can not legally transcode G729 in FreeSWITCH, >> PERIOD! >> >> /b >> >> On Jun 19, 2009, at 2:11 PM, JuanMa wrote: >> >>> Yes, it can do transcoding. Transcoding isn't the problem to my >>> architecture, my problem is the codec negotiation between FS and >>> Endpoints. >>> >> >> >> ___ >> Freeswitch-users mailing list >> Freeswitch-users@lists.freeswitch.org >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org > > > ___ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
