Re: [asterisk-users] Asterisk rewrites "From" header when CALLERID(num-pres)=prohib_passed_screen is set
When the date was Thu Jan 19 2012 15:23:04, Kevin P. Fleming wrote: > On 01/19/2012 05:56 AM, effie mouzeli wrote: >> When the date was Thu Jan 19 2012 12:12:04, Stefan Schmidt wrote: >> >>> Hello, >>> >>> IMHO asterisk acts exactly as it should. How else do you think it should >>> it prevent sending out the callerid name or num when you set it to prohib? >>> >> >> This behaviour is new in 1.8, since in 1.6 it work differently (not forcing >> the "From" header to the default asterisk caller ID). Does the RFC say that >> a UAS must change the "From" header to secure privacy, even though there is >> a special header for privacy (or set privacy=full in Remote-Party-ID)? >> >> In case asterisk is not functioning as a PBX but as intermediate proxy, how >> do we secure its interoperability with other systems? So the issue here is >> that we are unable to change/keep the "From" header when >> CALLERID(num-pres)=prohib_passed_screen is set. > > Asterisk cannot act as a proxy, it is a B2BUA. If you want to make its > behavior *appear* to be a proxy, there are a number of things you can do, but > it will never just 'pass along' headers from an incoming INVITE to an > outgoing INVITE. This is understandable. On the other hand, I cannot understand why asterisk sets the "From" header to "asterisk", even if we explicitly set the CALLERID(name) and CALLERID(num). -effie -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk rewrites "From" header when CALLERID(num-pres)=prohib_passed_screen is set
When the date was Thu Jan 19 2012 12:12:04, Stefan Schmidt wrote:
> Hello,
>
> IMHO asterisk acts exactly as it should. How else do you think it should
> it prevent sending out the callerid name or num when you set it to prohib?
>
This behaviour is new in 1.8, since in 1.6 it work differently (not forcing the
"From" header to the default asterisk caller ID). Does the RFC say that a UAS
must change the "From" header to secure privacy, even though there is a special
header for privacy (or set privacy=full in Remote-Party-ID)?
In case asterisk is not functioning as a PBX but as intermediate proxy, how do
we secure its interoperability with other systems? So the issue here is that we
are unable to change/keep the "From" header when
CALLERID(num-pres)=prohib_passed_screen is set.
> Asterisk doesnt support the privacy header for outgoing calls so
> changing the name and number is the only way to do this. Maybe you could
> do this in your dialplan with SipAddHeader("Privacy: full") instead of
> setting the prohib flag.
In http://tools.ietf.org/html/draft-ietf-sip-privacy-00:
6.2 UAS Behavior
A UAS supporting this extension and receiving an INVITE from its
trusted proxy looks for a Remote-Party-ID header field to identify
the originator of the request. If the Remote-Party-ID contains an
"rpi-screen" parameter with a value of "no", the UAS SHOULD NOT
trust the validity of the information provided. Otherwise, the UAS
SHOULD use the information provided to identify the caller rather
than any information provided in the From header field.
So even if asterisk doesn't support the "Privacy" header, it supports the
Remote-Party-ID header where the privacy=full parameter is present.
> in the Remote-Party-ID header is a special privacy option which asterisk
> sets when using this header so you will see the original values there
> but privacy is also set to full.
Kind Regards
-effie
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk codec negotiation and canreinvite=no
On Apr 11, 2011, at 8:38 pm, Paul Belanger wrote: > On 11-04-11 10:26 AM, Effie Mouzeli wrote: >> This may lead to some buggy clients not to accept the call (with 488), >> but I've noticed some cases where a callee was behind NAT, >> an INVITE with one video codec would me forwarded properly >> to the callee, but another INVITE with 3 video codecs, would >> never reach the callee, probably because it was never forwarded by >> the router (I still haven't been able to figure this out). >> > The code you are talking about underwent a complete rewrite [1] and has > already been merged into trunk[2]. Not that it helps you now, but you > may want to try testing with trunk (will become Asterisk 1.10) and see > if you have the same issues. > > This is one of the major milestones for Asterisk 1.10, and I'm sure any > feedback in testing will be much appreciated. > > [1] https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal > [2] http://svn.digium.com/view/asterisk?view=revision&revision=306010 Thank you very much for your input Paul, I will try to test it at some point. -effie -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk codec negotiation and canreinvite=no
Hi all, I realise that asterisk's codec negotiation has been discussed in the past multiple times. What I haven't been able to understand is how asterisk decides which video codecs to advertise to the other end when canreinvite=no in sip.conf and the initial caller doesn't support video. My tests are quite simple, I use an asterisk with 4 peers all on the same LAN. My sip.conf looks like that: [general] bindport=1628 videosupport=yes limitonpeers = yes sendrpid = yes trustrpid = no disallow=all allow = gsm # 3 allow = alaw # 8 allow = ulaw # 0 allow = g722 # 9 allow = g726 # 111 allow = h263 # 34 allow = h263p # 98 allow = h264 # 99 [peerA] type=friend secret=kokolala nat=no host=dynamic canreinvite=no context=koko dtmfmode=rfc2833 disallow=all allow = gsm allow = alaw allow = ulaw allow = g722 allow = g726 allow = h263 allow = h263p allow = h264 qualify=no For clients I use GXP-2000, X-Lite, Telephone and Linphone and in all my tests, one client was calling the other. When Linphone and X-lite are the initial callers, asterisk correctly adveritises h263 and h263p and not h264. GXP-2000 invites for instance X-lite Initial INVITE || Asterisk's INVITE -- 18 || 8 97 || 3 0 || 0 8 || 111 4 || 9 || 34 || 98 || 99 What I can't understand is: 1) Since in the initial INVITE there are no video codecs, why does asterisk decide to adveritise video codecs when inviting the other client. 2) When the initial INVITE comes from Telephone.app (no video), in version 1.6.2.17.2 asterisk advertises h263p (98) only. In version 1.8.3.2 (same configuration), using the same client, asterisk advertises all video codecs found in sip.conf (h263, h263p, h264). Is this the expected behavior? The problem raised here is that, in a production system, with videosupport=yes, for an audio-only call, asterisk will send invites where the SDP will have at least 1 video codec, but it may have 3 as well. This may lead to some buggy clients not to accept the call (with 488), but I've noticed some cases where a callee was behind NAT, an INVITE with one video codec would me forwarded properly to the callee, but another INVITE with 3 video codecs, would never reach the callee, probably because it was never forwarded by the router (I still haven't been able to figure this out). Cheers, -effie -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
