VoIP Mailing List Archives

[ujjval at simplesignal...]

Hi,

I used the downlaoded TAR ball and my calls worked, however, when upgrading to the SVN release...my SBC is rejecting the 200 OK (when the FS answers the call - using Conferencing app)..

Here are teh bad and good 200 OK,,,,I see a lot of additional headers startin gwith X:FS , can I remove them?

Bad one
-----------------
SIP/2.0 200 OK
v: SIP/2.0/UDP x.x.x.210:5060;branch=z9hG4bK1662379c08490b63b0b9be6978d93ebe
f: "SIMPLE SIGNAL "<sip:2222220208@x.x.x.20:5080;user=phone>;tag=945d1734da594444aac9d071edc798a7
To: "trunkgroup user" <sip:1111114847@simplesignal.net;ssig=33402ab16f12e359b1f871b80bf7ff1a>;tag=gX1Z34952QBpS
i: 674babc2dbf2a90da97bd68642865eae-23f978@x.x.x.210 (674babc2dbf2a90da97bd68642865eae-23f978@x.x.x.210)
CSeq: 3240 INVITE
Contact: <sip:1111114847@x.x.x.20:5080;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15225
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 249
X-FS-Display-Name: +11111114847
X-FS-Display-Number: +11111114847
X-FS-Support: update_display
P-Asserted-Identity: "+11111114847" <+11111114847>
v=0
o=FreeSWITCH 1256498762 1256498763 IN IP4 x.x.x.20
s=FreeSWITCH
c=IN IP4 x.x.x.20
t=0 0
m=audio 29406 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
------------------------------
Good One
-------------------------------
SIP/2.0 200 OK
v: SIP/2.0/UDP x.x.x.210:5060;branch=z9hG4bKffebde0efa06a6aa7772bae5ca085627
f: "SIMPLE SIGNAL "<sip:2222220208@x.x.x.20:5080;user=phone>;tag=895fd35d4979e6e5b0cdcc795b8c8df2
To: "trunkgroup user" <sip:1111114847@simplesignal.net;ssig=33402ab16f12e359b1f871b80bf7ff1a>;tag=KBXKrBQU99c6D
i: 28f0d47f1163e0d478247e6729762d98-23fedb@x.x.x.210 (28f0d47f1163e0d478247e6729762d98-23fedb@x.x.x.210)
CSeq: 3278 INVITE
Contact: <sip:1111114847@x.x.x.20:5080;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.4-exported
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
Supported: timer, precondition, path, replaces
Allow-Events: talk, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 249
v=0
o=FreeSWITCH 1256512215 1256512216 IN IP4 x.x.x.20
s=FreeSWITCH
c=IN IP4 x.x.x.20
t=0 0
m=audio 17376 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

[brian at freeswitch.org]

No you can't remove them... And they are 100% valid so your SBC is in the wrong.

/b

On Oct 26, 2009, at 12:05 AM, Ujjval Karihaloo wrote:

[kristian.kielhofner at...]

Brian,

This bothers me a bit.

Of course they are "valid". Anything prefixed with X- should be
ignored by the remote end unless they are specifically looking for it.

However:

1) We all know that just because the spec says they are valid doesn't
make it so with every vendor.
2) As long as these headers are being attached people are going to
keep coming to the list with issues because of them.
3) Attaching (seemingly arbitrary) headers like this breaks "interop
agreements" that we (the users) have with carriers and other vendors.
Every header we add is another reason why $CARRIER will refuse to
support me because "my INVITE doesn't match what I had during interop
testing".
4) Why do we /need/ these headers in the first place? What is using
them? If we don't really, really, really need them they shouldn't be
there.
5) Depending on the reason for them being there, this should still be
configurable. I just don't see why not. Obviously we could always
just patch the code (Sonus log statements but that probably
shouldn't be necessary here.

I'm not trying to be difficult; I'm just looking for a better
explanation and real discussion.

On Mon, Oct 26, 2009 at 10:35 AM, Brian West <brian@freeswitch.org> wrote:

[anthony.minessale at g...]

The headers are used to pass the callee-id info back to the other side so you have the id of who you called.
The standards have failed us in this case as everything does it differently to the point that there is no standard thus we have invented our own way to carry this across from one FreeSWITCH box to another, but of course we can never make anybody happy. =/


On Mon, Oct 26, 2009 at 10:15 AM, Kristian Kielhofner <kristian.kielhofner@gmail.com (kristian.kielhofner@gmail.com)> wrote:

[kristian.kielhofner at...]

Anthony,

So if I'm understanding you correctly, if you are always using
FreeSWITCH as an edge to other systems you should be able to safely
disable these headers?

On Mon, Oct 26, 2009 at 11:41 AM, Anthony Minessale
<anthony.minessale@gmail.com> wrote:

[tculjaga at gmail.com]

On Mon, Oct 26, 2009 at 4:41 PM, Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)> wrote:

[anthony.minessale at g...]

Thus perpetuating the wild-west of sip where you can't do anything according to spec because you have to worry about stupid things not keeping up.  Sounds like the education system where I live too.....

I'll see what I can do.  It's always the other end that ppl pay for that drive the free stuff to change its code.


On Mon, Oct 26, 2009 at 11:05 AM, Tihomir Culjaga <tculjaga@gmail.com (tculjaga@gmail.com)> wrote:

[mike at jerris.com]

New sofia profile param as follows:

<!-- set this param to false if your gateway for some reason hates X- headers that is is supposed to ignore--> <!--<param name="pass-callee-id" value="false"/>-->



On Oct 26, 2009, at 12:16 PM, Anthony Minessale wrote:

[anthony.minessale at g...]

This is ridiculous but here it is


try r15230

add the profile param

<param name="pass-callee-id" value="false"/>

 

On Mon, Oct 26, 2009 at 11:16 AM, Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)> wrote:

[kristian.kielhofner at...]

It is ridiculous but thank you very much!

On Mon, Oct 26, 2009 at 2:26 PM, Anthony Minessale
<anthony.minessale@gmail.com> wrote:

[tculjaga at gmail.com]

On Mon, Oct 26, 2009 at 7:26 PM, Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)> wrote: