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.h... 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:9499@[FS1 IP] SIP/2.0 Via: SIP/2.0/UDP [FS2 IP]:5060;branch=z9hG4bK60c74dbf;rport From: "[Source Number]" <sip:[Source Number]@[FS2 IP]>;tag=as3bd06925 To: <sip:9499@[FS1 IP]> Contact: <sip:[Source Number]@[FS2 IP]> Call-ID: 14b07c2014d3a0aa7719efa03d979eed@[FS2 IP] CSeq: 102 INVITE User-Agent: Legacy Max-Forwards: 70 Remote-Party-ID: "[Source Number]" <sip:[Source Number]@[FS2 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:9499@[AddPac IP] SIP/2.0 Via: SIP/2.0/UDP [FS1 IP];rport;branch=z9hG4bKXt9pr4er2H2Np Max-Forwards: 69 From: "[Source Number]" <sip:[Source Number]@[FS1 IP]>;tag=7ZDB1S0pFpSja To: <sip:9499@[AddPac IP]> Call-ID: 765f438b-26e6-122d-3490-51d73cb8d94c CSeq: 120957528 INVITE Contact: <sip:mod_sofia@[FS1 IP]:5060> 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]" <sip:[Source Number]@[FS1 IP]>;tag=7ZDB1S0pFpSja To: <sip:9499@[AddPac IP]>;tag=a34a0003a4 Call-ID: 765f438b-26e6-122d-3490-51d73cb8d94c CSeq: 120957528 INVITE Supported: timer, replaces, early-session User-Agent: AddPac SIP Gateway Contact: sip:9499@[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]" <sip:[Source Number]@[FS2 IP]>;tag=as3bd06925 To: <sip:9499@[FS1 IP]>;tag=6pmjZyFKjD3Ze Call-ID: 14b07c2014d3a0aa7719efa03d979eed@[FS2 IP] CSeq: 102 INVITE Contact: <sip:mod_sofia@[FS1 IP]:5060;transport=udp> 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_sofia@[FS1 IP]:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP [FS2 IP]:5060;branch=z9hG4bK56269b6a;rport From: "[Source Number]" <sip:[Source Number]@[FS2 IP]>;tag=as3bd06925 To: <sip:9499@[FS1 IP]>;tag=6pmjZyFKjD3Ze Contact: <sip:[Source Number]@[FS2 IP]> Call-ID: 14b07c2014d3a0aa7719efa03d979eed@[FS2 IP] CSeq: 102 ACK User-Agent: Legacy Max-Forwards: 70 Remote-Party-ID: "[Source Number]" <sip:[Source Number]@[FS2 IP]>;privacy=off;screen=no Content-Length: 0 I've tried the same test with different codecs, and it is always messing with the payload. Thanks in advance Regards M
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
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
Type 'sofia loglevel all 9' then 'sofia profile xxxx siptrace on' replace xxxx with the profile name then press F8 to turn debug log on Capture the whole thing and email me the log. I can pretty much tell you sofia is pissed about something in the SDP but I wanna see the logs. Thanks, Brian On Sep 29, 2009, at 12:40 AM, Mariano de Llano wrote:
What do you suggest me to do? (Use a hammer with my 3K AddPacs it's not an option) :D
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).
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
participants (2)
-
Brian West
-
Mariano de Llano