VoIP Mailing List Archives

[mariano.dellano at gma...]

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 [url=sip:9499@]sip:9499@[/url][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: <[url=sip:9499@]sip:9499@[/url][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 [url=sip:9499@]sip:9499@[/url][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: <[url=sip:9499@]sip:9499@[/url][AddPac IP]>
Call-ID: 765f438b-26e6-122d-3490-51d73cb8d94c
CSeq: 120957528 INVITE
Contact: <[url=sip:mod_sofia@]sip:mod_sofia@[/url][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: <[url=sip:9499@]sip:9499@[/url][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: [url=sip:9499@]sip:9499@[/url][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: <[url=sip:9499@]sip:9499@[/url][FS1 IP]>;tag=6pmjZyFKjD3Ze
Call-ID: 14b07c2014d3a0aa7719efa03d979eed@[FS2 IP]
CSeq: 102 INVITE
Contact: <[url=sip:mod_sofia@]sip:mod_sofia@[/url][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 [url=sip:mod_sofia@]sip:mod_sofia@[/url][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: <[url=sip:9499@]sip:9499@[/url][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

[brian at freeswitch.org]

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

/b

On Sep 28, 2009, at 11:08 PM, Mariano de Llano wrote:

[mariano.dellano at gma...]

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)

Thanks
Regards,
M





On 29/09/2009, ta 01:41, Brian West wrote:

[brian at freeswitch.org]

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:

[brian at 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:

[mariano.dellano at gma...]

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: